The practical vCard guide: versions, encoding traps, and import paths
vCard 2.1 vs 3.0 vs 4.0 and what breaks between them, multi-card files, the umlaut encoding trap, and import/export paths for every major platform.
A vCard is a plain-text file — open any .vcf in a text editor and you’ll see your contacts written out line by line. Which means almost every vCard problem is diagnosable with your eyes: the wrong version number, a multi-card file the importer half-read, or an encoding header that turned every ü into ü.
What’s inside a .vcf
Every card is a block of properties between BEGIN:VCARD and END:VCARD — a structured name (N), a display name (FN), then any number of TEL, EMAIL, ADR, ORG, NOTE, and PHOTO lines. The vCard glossary entry covers the format’s history; the practical point is that this is human-readable text with a paper trail of standards behind it: version 2.1 published by the versit Consortium (1996), 3.0 standardized as RFC 2426 (Dawson & Howes, 1998), 4.0 as RFC 6350 (Perreault, 2011).
That standards lineage is why the format works as an archive: a file readable by eye, specified in public documents, and importable by every contacts platform of the last twenty-five years is about as future-proof as data gets. It’s the format your annual contact backup should be in.
2.1, 3.0, 4.0 — and what breaks between them
vCard 2.1 is the mobile-phone era preserved in amber. Its defining quirk: non-ASCII text is encoded as quoted-printable, so Müller is stored as M=C3=BCller, with a charset declared per property. Importers that misread the declaration mangle every special character in the file. You’ll meet 2.1 in SIM tools, old Nokia/Outlook exports, and some budget Android dialers. Read it, don’t write it.
vCard 3.0 is the workhorse. It dropped quoted-printable for readable text, standardized the field set, and became what Google Contacts and iCloud actually emit when you click Export. Every platform that matters imports 3.0 cleanly. When any tool asks which version to export: this one.
vCard 4.0 is the best specification and the worst-supported. UTF-8 is mandatory rather than negotiated, fields are cleaner, and it can express things 3.0 can’t (per-property language tags, better typing). But fifteen years after RFC 6350, major platforms still export 3.0 and import 4.0 with varying enthusiasm — some silently downgrade or drop fields. Use 4.0 when both ends explicitly support it; never as a blind default.
What breaks at the seams is consistent: encoding (the 2.1 quoted-printable trap), field dialects (each version names some properties differently), and silent dropping — an importer that doesn’t recognize a property discards it without a word. Names, numbers, emails, and addresses survive every version boundary; photos, custom labels, and exotic fields are where the casualties happen.
Multi-card files: one .vcf, many contacts
A .vcf is a container, not a single card — cards simply follow each other in the file, and exporting 800 contacts produces one tidy text file. Two practical consequences:
Some importers only read the first card. Modern platforms handle multi-card files fine, but minimal and legacy importers — some SIM utilities, old desktop apps — process one card and quietly stop. If an 800-contact file imports exactly one person, this is why.
Splitting and combining is just text editing. Need to send one contact from a big export? Copy that BEGIN:VCARD…END:VCARD block into a new file. Need to merge three exports? Concatenate the files. No tool required — though after combining sources, expect overlaps, which is what a deduplication pass afterwards is for. Our contact deduplicator reads the combined file directly in your browser.
The umlaut test: encoding pitfalls
The most common vCard injury is mojibake: a file written in UTF-8 read as Latin-1 (or the reverse), turning ü into ü, é into é, ß into ß. Once garbled text is imported, no setting un-garbles it — the fix is always a fresh export, not a repair.
So make the check routine. Before any sizeable import, open the file and find a name with accents or umlauts. Reads correctly? Proceed. Reads like line noise? Stop, re-export in vCard 3.0 with UTF-8, check again. And a related warning from the spreadsheet world: this disease is far worse in CSV land, where opening and re-saving in Excel with the wrong locale destroys special characters permanently — one more reason vCard is the move-and-archive format and CSV the deliberate-editing format.
Import and export, platform by platform
-
Google Contacts
Export: contacts.google.com → Export → vCard. Import: contacts.google.com → Import → select the .vcf; on Android, Contacts app → Fix & manage → Import from file. Google labels each import batch with the date — useful for reviewing or undoing. Choose the destination account consciously if you carry two.
-
iCloud and macOS
Export: iCloud.com → Contacts → select all → gear icon → Export vCard; on the Mac, File → Export → Export vCard. Import: the gear icon’s Import vCard on the web, or drag the .vcf onto the macOS Contacts app. Check the sidebar account selection before confirming — that’s what decides where the cards land.
-
Android (local, no cloud)
Export: Contacts app → Fix & manage → Export to file (manufacturer apps: Settings → Import/Export). Import: Import from file in the same menu, then pick the target account — or “device” for a store that never syncs anywhere.
-
Outlook and everything else
Outlook’s classic desktop app is the awkward guest: its native exchange format is CSV, and its vCard handling has historically been single-card-minded. For Outlook moves, prefer the CSV route with explicit column mapping — and for any platform not listed here, the universal answer is: find the export, take vCard if offered, take 3.0 if asked.
The same format, live
One last connection worth making: vCard isn’t only the file format of exports — it’s also the record format of CardDAV, the open protocol that syncs address books between servers and devices. Learn the format once and you’ve understood both your backup files and the live sync underneath any standards-based setup, including the ones people land on after moving their contacts out of Google. Endearist sits on the same philosophy from the other side: contacts come in via vCard or CSV, and what you build on top stays in files you can always walk away with.
FAQ
What is a vCard file, in plain terms?
A **plain-text file** describing one or more contacts: each card starts with BEGIN:VCARD and ends with END:VCARD, with one property per line — name, phone numbers, emails, addresses, photo, notes. Because it's text, you can open a .vcf in any editor and read it. That transparency is the format's superpower: a vCard backup is verifiable with your own eyes, no special software required.
Which vCard version should I export — 2.1, 3.0, or 4.0?
**3.0 when in doubt.** It's the version Google Contacts and iCloud emit and the one every modern platform imports cleanly. Version 2.1 (1996) survives mainly in old phone and SIM tools and brings quoted-printable encoding headaches. Version 4.0 (RFC 6350, 2011) is technically the best — mandatory UTF-8, richer fields — but platform support remains the weakest of the three, so it's a poor default for exchange.
What actually breaks between vCard versions?
Mostly **encoding and field dialects**. Version 2.1 encodes non-ASCII characters as quoted-printable (=C3=BC for ü) and declares charsets per property; importers that misread this mangle every umlaut. Version 3.0 cleaned that up; 4.0 mandates UTF-8 outright. Field-wise, each version names some properties differently, and importers silently drop what they don't recognize — names and numbers survive everywhere, exotic fields don't.
Can one .vcf file contain my whole address book?
Yes — a .vcf is a **container**: cards simply follow one another in the same file, and a thousand-contact address book is one modest text file. The catch is on the import side: most modern platforms read all cards, but some older or minimal importers process **only the first card** and stop. If an import lands exactly one contact from a big file, that's the bug you've hit.
Why did my umlauts turn into ü after importing?
That's **mojibake**: the file is UTF-8, but the importer read it as Latin-1 (or vice versa), so ü becomes ü and ß becomes ß. It's the single most common vCard injury. The fix is to re-export rather than repair: take a fresh export in vCard 3.0 with UTF-8, and test-import a card containing a Müller before committing the full file.
How do I import a vCard into Google Contacts?
**contacts.google.com → Import → select the .vcf.** Google reads multi-card files fine and adds an automatic *Imported* label with the date, which makes undoing or reviewing the batch easy. On Android the same function lives in the Contacts app under **Fix & manage → Import from file**. Pick the destination account deliberately if you have more than one.
How do I import a vCard into iCloud or macOS Contacts?
On the web: **iCloud.com → Contacts → gear icon → Import vCard**. On a Mac, drag the .vcf into the Contacts app window, or use File → Import. Both routes handle multi-card files. One habit worth keeping: check which account (iCloud, Google, local) the app will write into before confirming — the sidebar selection at import time decides.
Can I edit a vCard file by hand?
Yes — it's text. Open the .vcf in any editor that respects UTF-8 (not Word), and you can fix a name, delete a card, or split a file by cutting BEGIN:VCARD…END:VCARD blocks. Two rules: keep each property on its own line, and don't touch the encoded photo blocks unless you mean to remove them. For bulk edits across hundreds of cards, a CSV detour is usually more comfortable.
vCard or CSV for moving contacts between platforms?
**vCard for fidelity, CSV for spreadsheets.** A vCard keeps multiple numbers per person, photos, and notes intact, and imports everywhere without column mapping. CSV flattens structure into rows, has incompatible dialects (Google's and Outlook's column names differ), and famously gets its umlauts destroyed by careless Excel saves. Move with vCard; reach for CSV only when you genuinely need to edit in bulk.
Does WhatsApp or my messenger read vCards?
Messengers use vCards mostly for **sharing single contacts in a chat** — that card someone sends you is a one-contact .vcf. For their main contact list they read your phone's address book rather than importing files. So the import path for a vCard backup is always the address book (Google, iCloud, the Contacts app), and messengers pick the contacts up from there.
How do I check a vCard file is healthy before importing it?
Open it in a text editor and look for three things: the **version line** (VERSION:3.0 is the safe case), a **card count** — search for BEGIN:VCARD and compare the count to what you expect — and a **non-ASCII spot-check**: find a Müller or a José and confirm the name reads correctly. Sixty seconds of looking prevents the classic half-imported, garbled batch.
What is CardDAV, and how does it relate to vCard?
**vCard is the data, CardDAV is the pipe.** CardDAV is the open sync protocol that servers and devices use to keep address books aligned — and the records it synchronizes are vCards. That's why understanding the format pays twice: the same knowledge covers your one-off export files and the live sync between your phone and any standards-based contact server.