What is a VCF file?

VCF is a plain-text format you can open in any editor. It is used for moving data between programs.

The extension is .vcf, and the full name is vCard Contact. Both matter less than what the file can hold, which is what the rest of this page is about.

It dates from 1995. The specification is RFC 6350.

A format that has been readable for that long is a format worth trusting with something you want back in ten years.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

VCF stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

Google Contacts, Apple Contacts and Microsoft Outlook read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

VCF is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

A phone. Almost always. Exporting contacts from Android, iPhone, Google Contacts or Outlook produces a VCF, and sharing a single contact by message or email attaches one too. It is the only format all of them agree on, which is why it survives despite being a design from 1995.

The other common source is a mail client. Signature blocks, address books and the little card attached to a business email are all vCards. If you have received a file called something like contact.vcf without asking for it, that is what happened.

This catches people out in both directions. A vCard shared from a phone contains one person; a vCard exported from an address book contains everybody, one after another in the same file, each between BEGIN:VCARD and END:VCARD lines.

So a 4 MB VCF is not a corrupted contact — it is your entire address book, and importing it will add every entry. Conversely, sending somebody your exported file to share one number hands over the lot. Open it in a text editor first if you are not sure which you have; the structure is obvious at a glance.

Three versions are in circulation and they are not interchangeable. Version 2.1 is from 1996 and encodes non-English text in ways modern software often misreads. Version 3.0 is the one most systems write. Version 4.0, specified in RFC 6350, is the current standard and is still not universally accepted.

RFC 6350 puts the VERSION line immediately after BEGIN:VCARD, but the older versions only require it somewhere in the card, so on a 2.1 file search for the word rather than reading line two. It is worth doing when an import goes wrong, because "this program will not read my contacts" is very often "this program does not accept 4.0" or "this file is 2.1 and the accents are being guessed at".

Version 4.0 settled on UTF-8 and the problem largely went away. Older files did not have that luxury: 2.1 used quoted-printable encoding with a character set declared per field, and plenty of software wrote it inconsistently.

The visible result is names with question marks, capital letters in odd places, or sequences like =C3=BC in the middle of a surname. That last one is quoted-printable showing through — the data is intact, the reader is not decoding it. Converting the file with a tool that understands the encoding fixes it; retyping four hundred names does not need to happen.

A vCard can embed a contact photograph as base64 text, and address books do this by default. It is the reason an export of eight hundred contacts is several megabytes rather than a few dozen kilobytes.

It is also the reason a VCF sometimes fails to import: some systems impose a size limit per card, and a high-resolution photograph pushes a single entry past it. If a bulk import stops partway through, an oversized photo on one contact is a likely cause and the file will tell you which one.

This is the most common conversion by a wide margin: contacts into a spreadsheet, for cleaning up duplicates, for a mail merge, or for importing into a system that only accepts CSV. The mapping works because most of a vCard is simple fields — name, organisation, telephone, email, address.

What does not map cleanly is repetition. A contact with four phone numbers and three email addresses has to become columns, and every tool chooses a slightly different set of column names. Structured names — the separate given, family and prefix parts — collapse into whatever the target expects, and embedded photographs are dropped. For deduplicating a list, none of that matters; for a lossless archive, keep the original VCF.

The reliable sequence is export to VCF, transfer the file, import. It works between Android and iPhone in both directions, and it does not depend on both devices trusting the same cloud account, which is the usual reason people are doing this manually in the first place.

Two things to check afterwards. Duplicates: importing without clearing the target first merges rather than replaces, and most address books deduplicate badly. And groups or labels: they are outside the core format, handled inconsistently, and are the thing most likely to arrive empty. The names and numbers travel reliably; the organisation around them frequently does not.