A contact spreadsheet and a vCard file describe the same people in very different ways. The safe conversion is not a blind format swap: map the columns, check which rows will import, choose the version your destination expects, and inspect the actual contacts before downloading.
A vCard is a structured contact record; .vcf is its normal file extension. One VCF can contain a single person or many consecutive vCards. That makes it useful for moving an address book into a phone, Apple Contacts, iCloud, Google Contacts, Outlook, or another contacts application without retyping each person.
Google Contacts can import either CSV or vCard, so direct CSV may already be enough when your headers match Google's template. VCF becomes more useful when another app expects vCard, when you want one portable multi-contact file, or when you need explicit contact properties instead of relying on an importer's CSV header guesses.
Keep one person or organization on each row and one kind of information in each column. Separate first and last names when the source has them, and keep mobile, work, and home phones in distinct columns. Do the same for work and personal email. A single mixed Phone column can still become a mobile number, but the converter cannot know its label from values alone.
Give every row a full name, at least one name component, or an organization. RFC 6350 requires a formatted-name property, and a blank contact is not useful even if it has a phone number. Preserve leading plus signs in international phones and keep postal codes as text so spreadsheet software does not remove zeros.
Clean duplicate or vague headers before mapping. If two columns are both named Phone, rename them to Mobile Phone and Work Phone. This makes the mapping reproducible and easier to review.
A deterministic mapper can recognize headers such as Given Name, Family Name, Mobile Phone, E-mail Address, Company, and Business Postal Code. Suggestions should come from header text only. Looking through contact values to infer meaning creates harder-to-explain mistakes and unnecessarily handles more personal data.
Review every suggested mapping. A source column should feed one vCard property, so selecting the same header elsewhere should move it instead of duplicating it silently. Unmapped columns remain out of the VCF. That is safer than dumping unknown columns into notes.
vCard 3.0 is the conservative compatibility choice. Apple documents that Contacts exports vCard 3.0, and many established import paths understand its familiar phone and email TYPE syntax. Use it unless your destination asks for something else.
vCard 4.0 is the current IETF format in RFC 6350. It requires UTF-8, CRLF line endings, escaped text values, a formatted name, and line folding around 75 octets; telephone values are URI-shaped. Choose it when the destination explicitly supports 4.0 or you control both sides of the workflow.
The version does not repair source data. Names, emails, phones, addresses, websites, birthdays, and notes still need correct mappings and valid values before either format imports well.
Preview several contact cards, but validate every row. Treat a missing name or organization as an error because the row cannot form a useful vCard. Treat malformed email addresses, incomplete website URLs, and impossible birthdays as property-level warnings: omit only that property and show exactly why.
Also flag repeated normalized emails or phone numbers as possible duplicate contacts. A duplicate signal is not proof - families and shared business lines are real - so review it rather than deleting automatically. Keep row numbers in the issue ledger so the source can be corrected directly.
After generation, inspect the formatted names, organizations, first email, and first phone in the preview. A syntactically valid VCF can still be semantically wrong if two source columns were mapped backwards.
Google's official flow accepts an existing CSV or vCard file. Use Import in Google Contacts, select the VCF, then review the created contacts. Google Contacts import help.
On Mac, double-click the VCF, drag it to Contacts, or use File - Import. iCloud.com also imports a vCard; Apple states that a file containing multiple people creates separate entries. Apple Contacts help and iCloud help.
Microsoft documents vCard import paths, but the exact bulk behavior differs across Outlook editions. Use the instructions for your version and test a small file before importing the full list. Outlook import help.
Contact lists are personal data. Prefer a converter that parses and generates the file inside the browser, does not persist rows, and does not send headers, field mappings, validation findings, previews, or VCF output to analytics. You should be able to use a sample, disconnect the network, and keep converting.
The csvtodashboard workflow follows that boundary. Its first-party audience counter receives only the page pathname and a coarse source category; it never receives contact data or interaction payloads derived from the file.
Load the CSV or Excel file, review the suggested contact-field mapping, choose vCard 3.0 or 4.0, inspect the preview and validation findings, then download one VCF containing every exportable contact.
Yes. vCard is the contact-data format; .vcf is its usual filename extension. A single VCF file may contain one or many vCard records.
Use vCard 3.0 for broad compatibility and Apple-style contact workflows. Choose 4.0 when the destination explicitly supports the current RFC 6350 format. The preview and validation are identical; only the serialized contact syntax changes.
Yes. The vCard grammar permits one or more vCard objects in the same entity, and iCloud documents importing a vCard that contains multiple people as separate contacts.
A row without a full name, any name component, or an organization is listed as an error and skipped. Invalid emails, websites, and birthdays are warnings; only the invalid property is omitted. Every row is checked, while the visible issue table is bounded.
No. Parsing, header matching, mapping, validation, preview, and vCard generation run in the browser tab. Contact values are not stored and are never included in first-party audience measurement.
Yes. Text values are escaped, output uses CRLF line endings, and long content lines are folded at UTF-8-safe 75-octet boundaries so multi-byte characters are not split.