Kinnetly
CSV vs vCard is mostly a question of where your contacts are coming from and how much you need to edit before they move. Choose vCard when your phone or address book produces complete contact cards. Choose CSV when you want to inspect a table, trim the list or correct clear fields before import.
Neither format is a complete copy of a relationship system. It may carry a name, email, phone number, company, title or note. It usually won't explain who introduced you, where you met or what you promised to do next.
The short answer
| Choose | Best fit | Watch for |
|---|---|---|
| vCard or VCF | Apple Contacts, phone address books and sources built around contact cards | Photos and notes may be optional, unsupported or too large |
| CSV | Google Contacts, Outlook and spreadsheets you want to review before import | Column headings must be recognised, and spreadsheets can alter phone numbers |
| Neither yet | You haven't tested what the destination accepts | Run a small sample before moving the full address book |
A .vcf file is a vCard file. The names are often used interchangeably in export menus.
Choose from the source, not the field count
It is tempting to pick whichever format seems to contain more fields. That can be the wrong test.
The vCard specification defines properties with meanings such as name, email, telephone, organisation, title, note and photo. A destination can read those properties without guessing what each column means.
CSV defines a common way to store rows and separated values. It doesn't define a universal contact layout. One file might say First Name; another might use Given Name. A contact importer needs to recognise those headings or ask you to map them.
Start with the cleanest native export your source offers. A format that leaves the source correctly is usually a better bet than a hand-built conversion with a longer feature list.
Where CSV earns its place
CSV is useful because you can see it.
Open a copy in a spreadsheet and you can remove contacts you don't want to bring across, check that one person occupies each row and reduce a large address book to a sensible starter set. Official exports from Google Contacts and Outlook also tend to use consistent headings that contact importers can recognise.
That visibility comes with risk. Spreadsheet software may remove the leading zero from a phone number, convert a long number to scientific notation or interpret a value as a date. Keep phone fields as text, and avoid renaming source headings unless the destination gives you a template.
Google Contacts supports both CSV and vCard imports. Its official import guidance includes a Google CSV template with named contact fields. That is a useful reminder that the shape of a contact CSV matters as much as the comma between each value.
Choose CSV when deliberate cleanup is part of the move. Keep the untouched export beside your working copy.
Where vCard earns its place
vCard is designed for exchanging contact records. It is often the simpler choice when the source is Apple Contacts, a phone or another address book that already stores each person as a contact card.
Apple Contacts can export selected contacts as one .vcf file. Apple also lets you decide whether notes and photos are included, according to its export guide. One file can contain several contacts, so don't assume that a multi-contact export needs to produce a folder full of files.
Choose vCard when the source offers it naturally and you don't need a spreadsheet cleanup step. If contact photos matter, include one in your test file and confirm that it arrives. Embedded media can make files larger, and destinations may ignore forms they don't support. Remote photo links aren't the same as an embedded image.
What neither file can carry reliably
A contact file can move facts about a person. Relationship context is a different kind of information.
Suppose you met Priya through Maya at a climate founders dinner. A standard contact export might contain Priya's name, company and email. It may contain a note if the source and destination both support that field. It probably won't rebuild Maya as the introducer, the dinner as an event and the connection between all three.
The same limit applies to groups, reminders, follow-up history and relationship links. If the source file never represented that structure, the destination cannot infer it safely. Don't fill the gap with guesses during import.
This is also why a contact import is different from a full personal CRM migration. A personal CRM export or backup may preserve a richer network model. CSV and vCard are better treated as ways to bring contact basics into a new system.
A safer seven-step import
- Keep the original export untouched. Make a working copy before opening it in a spreadsheet or converter.
- Choose the source's native format. Prefer an official Google or Outlook CSV, or the vCard export from an address book, over a hand-made file.
- Build a small test set. Include a two-part name, company, title, phone, email and note. Add a photo if you care about photos.
- Preview before importing. Check that fields land in the right places and that the total contact count makes sense.
- Review duplicate settings. Email and phone can help identify an existing contact, but neither is perfect. One person can use several addresses or numbers, and shared details need care.
- Import the test and inspect the records. Look at the destination, not just the success message.
- Move the rest, then add real context. Bring across the contact basics first. Add introductions, events and follow-ups only when you know they are correct.
If you receive the wrong format, Kinnetly's free vCard and CSV converter can help you inspect or convert the file. Conversion doesn't create missing context, so keep the original as your reference.
Check the edge cases that matter to you
A perfect test file is not representative if all its records are simple.
Include the awkward cases you would notice later: a phone number with a leading zero, a person with no email, a company name with punctuation, a note containing a comma and a contact with a photo. If your export contains many contacts, confirm that the sample came from the same export process as the full file.
Check duplicates by eye as well. An email- or phone-based skip can stop an exact matching detail from being imported twice, but it cannot know that two records with different details are the same person. Name-only duplicates need their own review.
What importing into Kinnetly looks like
Kinnetly accepts CSV and vCard or VCF contact files. It maps common Google and Outlook CSV headings, then shows a preview of names, emails, phones, companies and job titles before you import. The preview shows the first 15 parsed contacts and tells you how many more are in the file.
A Kinnetly contact import can bring in first name, last name, one email, one phone, company, job title and a recognised note. CSV doesn't currently carry a usable photo through the importer. A vCard can include an embedded photo when the image format is supported and the file is within the parser's limit.
The default duplicate control skips contacts whose email or phone number already exists, using a case-insensitive email comparison and a phone-number comparison against your contacts and the current import batch. It doesn't deduplicate by name. A single import is limited to 2,000 parsed contacts and remains subject to the contact allowance on your account.
Imported people appear under Contacts. A company value arrives as a field, not as a connected company node. Groups, events, introduction provenance, activities, reminders and graph links aren't rebuilt from a contact file. Those are the pieces to add deliberately once the right people are in place.
Choose the file your source handles cleanly, test it, and inspect what arrived. Then start a private relationship map in Kinnetly and add the context your address book could not carry.