VCF File Documentation

Summary

A vCard (Virtual Contact File) is a plain-text contact card that holds a person’s or organization’s details: name, phone, email, address, and sometimes a Base64-encoded photo. It is defined by the IETF, with vCard 4.0 standardised in RFC 6350 (2011). A single .vcf can store a whole address book as back-to-back cards, which is why it is the universal way to move contacts between phones. Its MIME type is text/vcard.

Technical details

FeatureValue
Full namevCard (Virtual Contact File)
File extension.vcf, .vcard
MIME typetext/vcard
Format typeLine-based plain text (property:value)
Character encodingUTF-8 (vCard 4.0); ASCII with quoted-printable in 2.1
DeveloperIETF; originally the Versit Consortium / Internet Mail Consortium
First introducedvCard 2.1 in 1996
Versions2.1 (1996), 3.0 (RFC 2426, 1998), 4.0 (RFC 6350, 2011)
StandardRFC 6350 (vCard 4.0); RFC 2426 (3.0)
Open standardYes — open IETF standard
Text markerBEGIN:VCARD on the first line (no binary signature)
Multiple contacts per fileYes — consecutive BEGIN/END:VCARD blocks
Required propertiesBEGIN, VERSION, FN, END (4.0)
Embedded photoYes — PHOTO property, usually Base64-encoded inline
Editable with text editorYes
OS compatibilityWindows, macOS, Linux, Android, iOS
Calendar counterpart.ics (iCalendar) — a separate standard for events
Related extensions.vcard, .ics, .csv, .ldif
Specificationdatatracker.ietf.org/doc/html/rfc6350
Structure at a glance

A vCard is UTF-8 text with no binary signature. Each contact is a block that opens with the line BEGIN:VCARD and closes with END:VCARD; the second line must be VERSION: (2.1, 3.0 or 4.0). Between them come property:value lines such as FN (formatted name), N (structured name), TEL, EMAIL, ADR and ORG. One file may hold many such blocks back to back. A UTF-8 byte-order mark (EF BB BF) may precede the first line.

What is a VCF file?

VCF stands for Virtual Contact File, and it holds one or more vCards, the internet standard for exchanging contact information. The format is defined by the IETF: the current version is vCard 4.0, published as RFC 6350 in 2011; the still-common vCard 3.0 is RFC 2426 (1998); and the original vCard 2.1 dates to 1996, when it came out of the Versit Consortium and the Internet Mail Consortium. A .vcf is plain text, so it opens in any editor, but its real job is to be imported into a contacts or address-book app. Its MIME type is text/vcard.

The whole format is line-based. Each contact is a block that starts with BEGIN:VCARD and ends with END:VCARD, and everything in between is a set of properties written as NAME:value. A single file can carry a whole phone’s address book by stacking those blocks one after another, which is exactly why a .vcf is the universal interchange and backup format for contacts. Everything below is about what those lines actually contain and how the versions differ.

The content line: property, parameters and value

Every line in a vCard follows one grammar, defined in RFC 6350 §3.3: an optional group, a property name, zero or more parameters, a colon, and the value. Parameters are separated from the property by semicolons, and each is a KEY=value pair.

[group.]NAME;PARAM=value;PARAM=value:VALUE

TEL;TYPE=work,voice;VALUE=uri:tel:+1-555-0100
       │    │                │
       │    │                └─ the value (a tel: URI in 4.0)
       │    └─ parameter list (this number is a work voice line)
       └─ property name

Two encoding rules matter when you read a raw .vcf. First, line folding: a logical line longer than 75 octets may be split, and each continuation line begins with a single space or tab that a parser strips before joining. That is why a long Base64 photo appears as many indented lines. Second, in structured values the comma separates repeated values and the semicolon separates the fields of a compound value, so a literal comma or semicolon inside text must be escaped with a backslash (\, or \;). Property names and parameter keys are case-insensitive; the convention is uppercase.

BEGIN, VERSION, N, FN and the required properties

A conformant vCard 4.0 must contain exactly four things in order: BEGIN:VCARD, a VERSION:4.0 line as the very next property, at least one FN, and END:VCARD. The VERSION line is not decoration; it selects the grammar the rest of the card is parsed under, and it must come immediately after BEGIN.

PropertyHolds
FNFormatted display name, e.g. FN:Dr. Jane Q. Public (required, repeatable)
NStructured name in five semicolon fields: family; given; additional; prefix; suffix
TELPhone number, typed with TYPE=cell/work/home
EMAILEmail address
ADRPostal address in seven semicolon fields (PO box; ext; street; city; region; postcode; country)
ORGOrganisation, with units separated by semicolons
TITLEJob title
PHOTOContact picture, usually Base64 data inline

The N property is the clearest example of the semicolon-as-field-separator rule. N:Public;Jane;Q.;Dr.; means family name Public, given name Jane, additional initial Q., prefix Dr., and an empty suffix. Applications build a display string from FN but sort and match on the components in N. A card can carry several TEL or EMAIL lines, each disambiguated by its TYPE parameter, which is why a spreadsheet export (see below) often cannot map a rich card cleanly.

A worked example, line by line

Here is a minimal but complete vCard 4.0 with two phone numbers and an email. Read it top to bottom: the VERSION gate, the structured and formatted names, typed phone lines, and the closing tag.

BEGIN:VCARD
VERSION:4.0
N:Public;Jane;Q.;Dr.;
FN:Dr. Jane Q. Public
ORG:Example Corp;R&D
TITLE:Research Lead
TEL;TYPE=work,voice;VALUE=uri:tel:+1-555-0100
TEL;TYPE=cell;VALUE=uri:tel:+1-555-0199
EMAIL;TYPE=work:jane@example.com
ADR;TYPE=work:;;100 Main St;Springfield;IL;62704;USA
REV:20240115T120000Z
END:VCARD

The REV line is a UTC revision timestamp; sync engines use it to decide which copy of a contact is newer during a merge. Because the file is just text, a second contact would begin on the next line with another BEGIN:VCARD, and a reader treats the file as a stream of independent cards.

What changed across vCard 2.1, 3.0 and 4.0

The three versions are not wire-compatible, and a card written for one will confuse a strict parser expecting another, which is the root of most “my contacts imported with garbled characters” complaints. The differences are concrete.

In 2.1, non-ASCII text and binary values are carried with explicit ENCODING=QUOTED-PRINTABLE or ENCODING=BASE64 parameters and a CHARSET, and type parameters are written bare (TEL;WORK;VOICE:) without a TYPE= key. 3.0 (RFC 2426) regularised parameters to the TYPE=work,voice form and made the character handling saner. 4.0 (RFC 6350) fixes the encoding on UTF-8 for the whole card, drops quoted-printable, expresses phone numbers and photos as URIs (including data: URIs for inline media), and adds properties such as KIND (to mark a card as an individual, group or organisation) and GENDER. When an old phone exports 2.1 and a new one expects UTF-8, accented names can arrive mojibaked; re-exporting as 3.0 or 4.0 usually fixes it.

The PHOTO property and why cards get large

A vCard can embed an image directly rather than linking to one. In 4.0 the value is a data: URI, for example PHOTO:data:image/jpeg;base64,/9j/4AAQ…, and the Base64 payload is folded across many space-prefixed continuation lines. Base64 inflates binary by about a third, so a single contact card with a photograph can run to tens of kilobytes of text, and an address book full of photos becomes a surprisingly heavy .vcf. That is also why opening such a file in a text editor shows long runs of seemingly random characters between readable fields: those are the encoded images, not corruption.

VCF holds contacts, ICS holds events

vCard is strictly a contacts format: it describes people and organisations, not appointments. Its calendar counterpart is iCalendar (.ics), a different IETF standard (RFC 5545) for events, to-dos and free/busy time. The two look similar on the surface because both are line-based text with BEGIN/END blocks and folded lines, but they are not interchangeable, so “convert VCF to ICS” is a category error: there is no sensible way to turn a person into an event. If you want someone’s birthday on a calendar you create a calendar event; you do not convert their vCard. The genuinely useful data conversion is VCF to CSV, flattening each card into a spreadsheet row for editing, de-duplication or mail merge. That mapping is lossy exactly because of the multi-value properties described above: a contact with three phone numbers and two emails does not fit one clean set of columns.

Frequently asked questions

Why can one .vcf hold hundreds of contacts?

Because the format is a stream of self-contained blocks. Each contact is a complete BEGIN:VCARD…END:VCARD unit with its own VERSION, and a reader simply processes them one after another. Nothing in the file links the blocks, so exporting a whole address book is just a matter of concatenating every card into one text file.

Why did my imported names come out garbled?

Almost always a version and encoding mismatch. vCard 2.1 uses quoted-printable with an explicit charset, while 4.0 assumes UTF-8 throughout. If a card was exported as 2.1 and read by a tool expecting UTF-8, accented or non-Latin characters get mangled. Re-exporting the source as vCard 3.0 or 4.0 usually resolves it.

Why is VCF to CSV sometimes lossy?

A vCard can repeat properties: several TEL lines, several EMAIL lines, each typed differently. A CSV row has fixed columns, so a contact with more phones or emails than the template allows loses the extras or spills them into generic columns. Contacts with a single phone and email convert cleanly; rich cards do not.

References