vCard
A VCF file stores structured contact data — names, phones, emails, photos — in the vCard format (RFC 6350). Despite universal use, 'VCF' has no official expansion: the Library of Congress confirms neither 'Virtual Contact File' nor 'Virtual Card Format' appears in any spec.
VCF conversion is not yet available in FileDex. Use the CLI commands in the Technical Reference below to convert between contact card formats.
Common questions
What is a VCF file?
VCF (vCard) stores structured contact information — names, phone numbers, emails, addresses, and photos — as plain-text property lines in a format defined by RFC 6350. Every smartphone, email client, and contact manager reads this format natively. A single .vcf file can contain one contact or an entire address book.
How do I open a VCF file?
Double-click on Windows to import into Outlook or Windows Contacts. On macOS, double-click opens Apple Contacts with a preview. On Linux, use GNOME Contacts, Evolution, or Thunderbird. The file is plain text — any text editor shows the raw property lines.
How do I import VCF contacts to my phone?
On iPhone, email the .vcf file to yourself and tap it, or sync via iCloud Contacts. On Android, open the file from Files or Gmail — the system offers to add each contact. Google Contacts web interface also accepts VCF uploads via its Import function.
What's the difference between VCF and CSV for contacts?
VCF preserves structured fields — multiple phone numbers with TYPE labels (home, work, cell), multi-line addresses, and embedded photos. CSV flattens everything into columns, losing field hierarchy and requiring custom column naming. VCF is standardized by RFC 6350; CSV column names are not standardized for contacts.
How do I merge multiple VCF files?
Concatenate them: `cat file1.vcf file2.vcf > merged.vcf` on Linux/macOS, or `type file1.vcf file2.vcf > merged.vcf` on Windows. Each vCard is self-contained between BEGIN:VCARD and END:VCARD markers, so concatenation produces a valid multi-card file.
Can a VCF file contain photos?
Yes. vCard 2.1 and 3.0 embed photos as base64-encoded data inline, adding 30-50% size overhead per image. vCard 4.0 supports URI references — either data: URIs with base64 or external HTTPS URLs — which can eliminate file bloat when the URL points to a hosted image.
What is the difference between vCard 3.0 and 4.0?
vCard 4.0 (RFC 6350, 2011) mandates UTF-8 as the only charset, replaces inline base64 photos with URI references, makes the N property optional (3.0 required it), and adds GENDER, ANNIVERSARY, and KIND properties. It removed QUOTED-PRINTABLE encoding remnants and the AGENT, LABEL, and CLASS properties from 3.0.
What makes .VCF special
What is a VCF file?
VCF stores structured contact data as plain-text property lines delimited by BEGIN:VCARD and END:VCARD markers. Each property follows a key:value pattern — FN for the display name, TEL for phone numbers, EMAIL for addresses, PHOTO for embedded images. A single .vcf file can contain one contact or thousands, concatenated back-to-back. Every major operating system, smartphone, and email client reads and writes this format natively.
Continue reading — full technical deep dive
Three versions, three encoding eras
vCard has passed through three incompatible specification versions, each changing how text and binary data are encoded:
vCard 2.1 (1995) — Published by the Versit Consortium, a joint effort of Apple, AT&T, IBM, and Siemens. This pre-RFC version introduced QUOTED-PRINTABLE encoding for non-ASCII text and BASE64 for inline photos. The VERSION, N, and END properties were all optional. Line folding was informal.
vCard 3.0 (RFC 2426, September 1998) — The first IETF standard. Authors Frank Dawson (Lotus) and Tim Howes (Netscape) eliminated QUOTED-PRINTABLE encoding entirely, requiring 'B' (base64) for all inline binary. The FN, N, and VERSION properties became mandatory. The CHARSET parameter still existed, allowing encodings other than UTF-8.
vCard 4.0 (RFC 6350, August 2011) — The current standard, authored by Simon Perreault. UTF-8 became the only permitted charset — the RFC states explicitly: 'There is no way to override this.' The N property dropped back to optional (only FN and VERSION are required). PHOTO switched from inline base64 to URI references, including data: URIs. Properties like NAME, MAILER, LABEL, CLASS, and AGENT were removed. New properties GENDER, ANNIVERSARY, KIND, and LANG were added.
The practical impact: a vCard 2.1 file exported from an old Nokia phone, a 3.0 file from Outlook 2010, and a 4.0 file from an iPhone 15 use different encoding schemes for the same contact data. Importing all three into one address book triggers charset detection failures, malformed base64 errors, and missing fields.
Property structure
A minimal valid vCard 4.0 file:
BEGIN:VCARD
VERSION:4.0
FN:Ahmed Al-Rashid
TEL;TYPE=cell:+966501234567
EMAIL:ahmed@example.com
END:VCARD
VERSION must appear immediately after BEGIN:VCARD in v4.0 — earlier versions allowed it anywhere or even omitted it. Property names are case-insensitive but the RFC recommends uppercase on output. Semicolons separate compound fields: the N property uses N:Last;First;Middle;Prefix;Suffix. Commas, semicolons, and backslashes in values must be escaped with a backslash.
Photo embedding and file size
Contact photos are the primary cause of VCF file bloat. A single high-resolution JPEG encoded as base64 adds 30-50% overhead to its original size, easily pushing a single contact card past 100 KB.
v2.1: PHOTO;ENCODING=BASE64;TYPE=JPEG: followed by raw base64 data.
v3.0: PHOTO;ENCODING=b;TYPE=JPEG: — shorter encoding parameter name, same base64 payload.
v4.0: PHOTO:data:image/jpeg;base64,<data> using standard data URIs, or PHOTO:https://example.com/photo.jpg for external references.
The URI approach in v4.0 eliminates inline bloat entirely — the vCard stores a URL, not the image bytes. But most contact apps still embed photos inline for offline reliability, making v4.0's size advantage theoretical for consumer use.
Line folding
RFC 6350 Section 3.2 specifies that content lines should fold at 75 octets maximum. Folding inserts a CRLF followed by a single whitespace character (space or tab). The next line continues the property value. Unfolding removes both the CRLF and the leading whitespace — this differs from email header unfolding (RFC 5322), which preserves the whitespace.
Multi-octet UTF-8 characters must not be split across the fold boundary. A 3-byte Arabic character at position 74 forces the fold to occur at position 73 instead.
Real-world usage
WhatsApp's 'Share Contact' feature sends a VCF attachment. iPhone Settings > Contacts > 'Export vCard' produces VCF files used for phone migration. Google Contacts exports entire address books as a single multi-card VCF. Android's contact picker generates VCF for sharing via Bluetooth, NFC, and messaging apps.
QR codes encoding vCard data are standard on business cards — the entire BEGIN:VCARD...END:VCARD text becomes the QR payload, and scanning phones automatically offer to add the contact.
CardDAV: live contact sync
CardDAV (RFC 6352) extends WebDAV to synchronize vCard data between clients and servers. iCloud Contacts, Google Contacts, and Nextcloud all use CardDAV for real-time contact sync. The protocol operates on individual vCard resources identified by URLs, supporting create, read, update, and delete operations. CardDAV is to contacts what CalDAV is to calendars. Apple, Google, and Microsoft all implement CardDAV in their contact services, making it the backbone of cross-platform contact synchronization.
What VCF cannot do
vCard has no encryption mechanism — contact data is always plaintext. There is no digital signature support for verifying that a received vCard hasn't been tampered with. Photo bloat remains unsolved for offline-first applications. Version incompatibilities between 2.1, 3.0, and 4.0 cause import failures that users cannot diagnose without inspecting the raw text. The format carries no schema version negotiation — a parser must read the VERSION line and branch its logic accordingly.
.VCF compared to alternatives
| Formats | Criteria | Winner |
|---|---|---|
| .VCF vs .CSV | Data structure VCF preserves hierarchical contact fields (multiple phones with TYPE labels, structured addresses with street/city/postal components). CSV flattens everything into columns, losing structure and requiring custom column naming conventions. | VCF wins |
| .VCF vs .CSV | Photo support VCF embeds photos inline via base64 (v2.1/3.0) or references them via URI (v4.0). CSV has no native binary embedding — photo paths can be listed as text but the images themselves live elsewhere. | VCF wins |
| .VCF vs .CSV | Multi-value fields A single VCF contact can have 3 phone numbers with TYPE labels (home, work, cell). CSV requires either 3 separate columns (Phone1, Phone2, Phone3) or delimiter-separated values in one cell. | VCF wins |
| .VCF vs .CSV | Standardization VCF is defined by RFC 6350 with formal property names, value types, and encoding rules. CSV has only RFC 4180 covering basic delimiter syntax — no standard for column naming or data types. | VCF wins |
| .VCF vs .LDIF | Directory integration LDIF is native to LDAP directory services used in enterprise environments (Active Directory, OpenLDAP). VCF requires conversion for LDAP import. | LDIF wins |
| .VCF 4.0 vs .JCARD (RFC 7095) | Web API compatibility jCard represents vCard data as JSON arrays, native to REST APIs and JavaScript. VCF's text/vcard format requires a dedicated parser. jCard is used in RDAP domain registration data. | JCARD wins |
Technical reference
- MIME Type
text/vcard- Developer
- Internet Mail Consortium / IETF
- Year Introduced
- 1995
- Open Standard
- Yes — View specification
Binary Structure
VCF is a plain-text format delimited by BEGIN:VCARD and END:VCARD markers. Each property occupies one logical line in key:value format (e.g., FN:Ahmed Al-Rashid). Parameters appear between the property name and colon, separated by semicolons (e.g., TEL;TYPE=cell:+966501234567). Photos are base64-encoded inline (v2.1/3.0) or referenced via URI (v4.0). Multiple vCards can be concatenated in one file. Lines fold at 75 octets per RFC 6350 §3.2 — a CRLF followed by whitespace indicates continuation.
| Offset | Length | Field | Example | Description |
|---|---|---|---|---|
Line 1 | 12 bytes | BEGIN marker | BEGIN:VCARD | Indicates the start of a vCard record |
Line 2 | variable | VERSION | VERSION:4.0 | vCard specification version (2.1, 3.0, or 4.0) |
Line 3 | variable | FN (Full Name) | FN:Alice Johnson | Formatted display name of the contact |
Last line | 10 bytes | END marker | END:VCARD | Indicates the end of a vCard record |
Attack Vectors
- Malformed base64 photo data can exploit image parser vulnerabilities in contact applications during import
- Oversized VCF files with thousands of contacts or large inline photos can cause denial-of-service in import routines
- URL properties (PHOTO URI, URL) can point to tracking pixels or malicious sites that load when a contact app fetches the resource
Mitigation: FileDex does not import, execute, or parse VCF files. This is a reference page with CLI inspection commands. Contact apps should validate base64 data length and sanitize URLs before fetching external resources.
- Specification RFC 6350 — vCard Format Specification (v4.0)
- Specification RFC 2426 — vCard MIME Directory Profile (v3.0)
- Registry IANA Media Type: text/vcard
- Registry LOC Format Description — Virtual Card Format (vCard)
- History vCard — Wikipedia