Skip to content
OneKitly
Sign up · Sign in

Three vCard Versions, and the Same Person in Each

Published 9/9/2026 · 3 min read · File tools

Daniel Okonkwo

Daniel Okonkwo — Front-end developer and tech writer at OneKitly

Web performance · File formats

Checked against 3 sources

View profile →
In short

The version is on the second line of every card, right after BEGIN:VCARD, and it changes how the rest is written. In 2.1, still produced by older phones and mail clients, a type is a bare parameter: TEL;CELL and TEL;WORK;VOICE, no equals sign. In 3.0, which almost every address book exports and everything reads, the same line is TEL;TYPE=CELL and TEL;TYPE=WORK,VOICE. In 4.0, the current standard, many values become URIs: TEL;VALUE=uri:tel:+33612345678, and a birthday is written 19780412 rather than 1978-04-12. The viewer reads all three, which is why a card from a 2009 phone and one from this year's address book display side by side — but it does not rewrite them into each other, so a 4.0 phone number keeps its tel: prefix and a 4.0 birthday keeps its compact form. When you write, 3.0 travels furthest.

2.1 marks types without an equals sign, 3.0 is what everything reads, 4.0 writes some values as URIs — so a phone can arrive as tel:+33612345678, prefix included. Knowing which you have explains most import surprises.

Why three versions are all still in circulation

Address books are copied forward, not rewritten. A card created on a phone in 2008 has been exported, imported and re-exported a dozen times since, and every one of those steps preserved the version it was born in unless something deliberately upgraded it. The result is that a working address book is often a mixture, and a file of five hundred contacts can contain all three — which is why a reader that only handles one of them appears to lose contacts at random.

The parser here takes the parameters as they come — with an equals sign or without — which is what lets a mixed file open in one go. What it will not do is silently normalise a card from one version into another, because that would be an edit, and an edit you did not ask for is the last thing you want applied to five hundred contacts at once.

The same contact written three ways
LinevCard 2.1vCard 3.0vCard 4.0
MobileTEL;CELL:TEL;TYPE=CELL:TEL;TYPE=cell;VALUE=uri:tel:
BirthdayBDAY:19780412BDAY:1978-04-12BDAY:19780412
Read by the viewerYesYesYes, prefix kept
Best for writingNo — legacyYesOnly if the destination asks for it
VCF viewerOpen a .vcf file and read the contacts it holds, without importing them anywhere.Try the tool →

Frequently asked questions

How do I find out which version a file uses?
Open it in any text editor and read the second line: VERSION:2.1, VERSION:3.0 or VERSION:4.0. A single .vcf can hold hundreds of cards and they can be of different versions, since a file is just cards written one after another — an address book assembled from several sources often is.
My imported numbers start with tel:. How do I clean that up?
That is a 4.0 file read literally. Export to CSV, remove the prefix with a find-and-replace across the phones column, and rebuild the .vcf from the corrected sheet — the round trip costs you the type labels, which a 4.0 URI number had already made awkward anyway. If you have only a handful, editing them in the destination is quicker.
Do accented names and photos survive between versions?
Names do: all three versions carry UTF-8 in practice, and the viewer decodes what it reads. Photos are a different matter — an embedded PHOTO is base64 inside the card and can make a single contact hundreds of kilobytes, and neither the CSV nor the JSON export carries it. If your cards have photographs, keep the .vcf as the copy of record.

Articles you may find interesting

All guides →
ExplainerA vCard Address Has Seven Parts, and a CSV Column Has OneNames, addresses and organisations are structured fields in a vCard. Flatten them into a spreadsheet and they read identically while losing the seams — which matters the moment you build a vCard back out of that spreadsheet.ComparisonTwo Emails in One Cell, or Two Strings in an ArrayA contact can have several phone numbers and several addresses. The CSV joins them with a middle dot into one cell; the JSON keeps them as a list, which is the difference between a script that works and one that splits on a guess.How-toMerging Calendars and Address Books Appends — It Does Not DeduplicateThe merge tools put every record from every file into one output, in the order you gave them. That is the right default and the one thing to know before you feed in two exports of the same account.How-toYou Do Not Have to Rename Your Columns to EnglishThe header row is matched in six languages, so prénom, apellidos, Vorname and cognome are all understood. One header is genuinely ambiguous — nom — and it is settled by the column next to it.ComparisonThe JSON Export Keeps Three Things the CSV Has No Column ForSame file, same parser, two outputs. The spreadsheet gets eight columns; the JSON gets the named time zone, the all-day flag and the recurrence rule as well.ExplainerThe Same .ics File Can Mean Five Different TimesiCalendar writes a start time in one of three ways, and only one of them is unambiguous. A meeting written with a named zone, converted on machines in Paris, New York and Honolulu, spanned nineteen hours and changed day.

Related tools

VCF viewerOpen a .vcf file and read the contacts it holds, without importing them anywhere.VCF to CSVTurn a vCard address book into a spreadsheet-ready CSV, one contact per row.VCF to JSONExport a vCard address book as structured JSON, with emails and phones as arrays.Merge VCF filesCombine several vCard files into a single address book you can import once.

Sources

Spotted a mistake in this article?