You export an address book from one provider and import contacts into another, and it feels like a solved problem right up until you look at what arrived. The names are there. The primary email is there. The second phone number, the postal address, the job title from before the promotion, and the note you wrote in 2021 about who introduced you — those are gone, and nothing told you.
The cause is almost always the file format. When you import contacts from a CSV you lose everything the spreadsheet had no column for, and a spreadsheet is a rectangle while a contact isn't.
Here is what each format keeps, how to move an address book without shedding data, and what to do about the duplicates you'll inevitably create.
A Contact Is Not a Row
A spreadsheet row has one value per column. A real contact has:
- Several email addresses, each with a label — work, home, the old one that still forwards.
- Several phone numbers, likewise.
- Postal addresses that are structured, not one string.
- An organisation and a job title that change over time.
- Free-form notes of arbitrary length, frequently containing commas and line breaks.
- A photograph.
- Group memberships — a contact can be in several at once.
Flattening that into a rectangle requires deciding, for each repeating field, either to keep only the first one or to invent columns like email_2, email_3. Every tool decides differently, which is why a CSV exported from one system and imported into another loses whatever the two disagreed about.
The losses are silent. There's no warning, because from the importer's point of view nothing failed — it read every column it recognised. The columns it didn't recognise were simply not there.
vCard vs CSV When You Import Contacts
| vCard (.vcf) | CSV | |
|---|---|---|
| Multiple emails and phones | Yes, with labels | Only if the exporter invented columns, and only if the importer guesses the same ones |
| Structured postal addresses | Yes | Usually one flattened string |
| Photos | Yes, embedded | No |
| Notes with commas or line breaks | Fine | Fragile — a common source of shifted columns |
| Groups | Yes | No |
| Editable in a spreadsheet | No | Yes |
| Human-readable diff | Reasonably | Yes |
vCard, standardised as RFC 6350, is the format every serious address book speaks — Google Contacts, Outlook, Apple Contacts and every phone. It represents repeating labelled fields natively, which is precisely the thing CSV can't do.
Default to vCard whenever you import contacts in bulk. The only reason to reach for CSV is that you need to edit the data on the way through, and that reason is real often enough to deserve its own section.
When CSV Is the Right Way to Import Contacts
CSV wins when the data needs work: deduplicating a list assembled from three sources, fixing capitalisation, filling in a company column, or dropping everyone who hasn't been contacted since 2019. Those are spreadsheet jobs, and no address book UI does them well.
To import contacts from CSV you need a header row. These columns are recognised, case-insensitively:
| Column | Maps to | Required |
|---|---|---|
email or email_address | Primary email | Yes |
name, or first_name + last_name | Contact name | No |
company or organization | Company | No |
job_title or title | Job title | No |
phone | Phone number | No |
address | Postal address, any format | No |
birthday or birth_date | Date, YYYY-MM-DD | No |
notes | Free-form notes | No |
Unrecognised columns are ignored rather than causing a failure, and empty cells are stored as empty rather than rejecting the row. Both are deliberate — one bad cell shouldn't stop you importing four thousand contacts.
Two spreadsheet hazards worth naming. Phone numbers with a leading + or leading zeros are frequently mangled into numbers by Excel and Sheets; format the column as text before you save. And a value beginning with =, +, or - is interpreted as a formula, which is a genuinely destructive default.
Whichever format you use, you get a preview before you import contacts for real: how many were found, the first few entries so you can spot a column-mapping mistake, and any rows that failed validation. Read it. A misaligned column is obvious in the preview and very tedious to unpick afterwards.
What Happens When You Import Contacts That Already Exist
The interesting case isn't the empty address book. It's when you import contacts that partly overlap what you already have.
The naive behaviour — and the behaviour of a lot of import tooling — is to overwrite the existing contact with the incoming one. That looks correct on the surface and quietly destroys data: the incoming record came from a CSV with four columns, the existing one had a mobile number, a postal address, and three years of notes, and now it has four fields.
Here, importing merges rather than replaces. Fields present in the incoming record update the existing contact; fields absent from it are left alone. Add a company column to two hundred contacts and you get the company plus everything that was already there.
This is the behaviour you want and it's worth checking for in any tool you use, because the alternative is unrecoverable and doesn't announce itself.
The Duplicate Problem
Every address book accumulates duplicates, and importing creates them faster than anything else. The same person appears as anna@acme.com, a.smith@acme.com, and anna.smith@gmail.com, all real, all hers.
Automatic deduplication can't solve this, and tools that claim to will merge two different people who share a name. Matching on email address is safe and catches the easy cases. Matching on name isn't — it's how a company ends up with one contact record containing two people's phone numbers.
What actually works: import contacts, then sort by name and scan. Ten minutes on a list of two thousand finds the real duplicates, and a human deciding "these two are the same person" is the only reliable version of that judgement.
Better still, prevent them. A contact created from an incoming message uses that message's address; a contact typed by hand uses whatever the person remembered. Consistently using the former is most of the fix.
Sync Instead of Import
When you import contacts you make a one-time copy. If you want your phone and your webmail to hold the same address book continuously you want sync instead, and the protocol for that is CardDAV.
CardDAV is to contacts what IMAP is to mail: the address book lives on the server and every client reads and writes the same copy. Add a contact on your phone and it's in webmail immediately, with no export step and no divergence.
Apple Contacts on macOS and iOS support it natively. Android needs DAVx⁵. Thunderbird supports it directly. Outlook needs a third-party plugin — the one meaningful gap.
Setup guides: Apple on macOS, iPhone and iPad, Android with DAVx⁵, Thunderbird.
Sync also removes the failure mode where the phone's copy and the desktop's copy diverge for two years and then one of them overwrites the other.
Moving an Address Book
- Export as vCard from the old provider. Google Contacts, Outlook, and Apple Contacts all offer it. Only use CSV if you've editing to do.
- Open the file and look at it. A vCard is text. Confirm that a contact you know is complicated came through with everything.
- Clean in a spreadsheet if you need to — and if you do, expect the loss described above, so keep the vCard as the authoritative copy.
- Import contacts and read the preview. Check the count and the sample rows before confirming.
- Spot-check afterwards. Open the same complicated contact and compare it against the source.
- Deduplicate by hand, sorted by name.
- Set up CardDAV on your devices so this is the last time you do any of it.
- Keep the export file somewhere safe for a few months.
You can also import contacts over the API or through an MCP server, including group membership — useful when the address book is being assembled from a CRM rather than moved from another mail provider.
Frequently Asked Questions
Which format should I use to import contacts?
vCard, unless you need to edit the data on the way through. It carries multiple labelled emails and phones, structured addresses, photos, and groups; CSV carries one value per column and silently drops the rest.
Will importing overwrite my existing contacts?
No. Fields present in the incoming record update the contact; fields it doesn't mention are left alone. Adding one column to an existing contact doesn't erase the rest of it.
Why did my phone numbers come out wrong?
A spreadsheet treated them as numbers and dropped the leading + or leading zeros. Format the column as text before saving, or use vCard.
Can I import contacts that have no email address?
CSV requires an email column, so a contact without one has no key to import on. vCard handles them, since a vCard contact doesn't have to have an email address.
How do I get contacts onto my phone?
Set up CardDAV rather than importing. The address book then lives on the server and every device reads the same copy — no export, no divergence.
Does it deduplicate when I import contacts?
Only matching on email address, which is safe. Matching on name isn't, because two different people frequently share one. Sort by name and review after a large import.
Can I export my contacts out again?
Yes, in the same formats. Export before any large change — an export you didn't need costs nothing.
What happens to contact groups?
vCard carries group membership; CSV doesn't. Group membership can also be managed over the API and MCP, which is the practical route when the source is a CRM export.
