vCard 2.1 vs 3.0 vs 4.0: Every Difference That Matters

Introduction

The three vCard versions are not just incremental updates. Each version changes how properties are declared, how non-ASCII characters are encoded, how photos are embedded, and which properties are available. A vCard 2.1 file from a Samsung phone and a vCard 4.0 file from an iPhone use fundamentally different syntax for the same contact information, which is why importing between platforms often produces errors or loses data.

This guide compares every significant difference between the three versions, organized by category. The goal is to give you a clear reference for understanding why a specific file behaves the way it does, why certain platforms produce certain formats and which version fits your specific needs.

Version Overview: Release Dates and RFCs

vCard 2.1 was published in 1996 by the Versit Consortium (founded by Apple, AT&T, IBM, and Siemens). It defined the basic vCard structure: BEGIN/END delimiters, property-value pairs, and type parameters. It was never published as an IETF RFC, which means it has no formal internet standard status. Despite this, vCard 2.1 remains in active use because Android and several legacy email clients still export in this format.

vCard 3.0 was published in 2001 as RFC 2425 (MIME content type) and RFC 2426 (vCard specification). It standardized the format under IETF governance, improved Unicode support, and formalized parameter syntax. vCard 3.0 is the most widely supported version and the default export format for Google Contacts, iCloud and Outlook.

vCard 4.0 was published in 2011 as RFC 6350. It mandated UTF-8 encoding, added new properties for richer contact representation, introduced XML (xCard, RFC 6351) and JSON (jCard, RFC 7095) alternative formats, and cleaned up several ambiguities from earlier versions. Adoption has been slower than expected, with most platforms still defaulting to vCard 3.0 for exports.

Character Encoding

Encoding is the most impactful difference between versions and the primary cause of cross-version import errors.

vCard 2.1 does not specify a default character encoding. Properties with non-ASCII characters must declare both their encoding method and character set explicitly: FN;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:M=C3=BCller. The CHARSET parameter can be UTF-8, Windows-1252, Shift-JIS, or any other encoding the exporting system uses. Quoted-printable encoding represents each non-ASCII byte as =XX (equals sign plus two hex digits).

vCard 3.0 assumes UTF-8 by default but does not mandate it. The CHARSET parameter is deprecated (it should not appear in vCard 3.0 files, though some implementations still include it). Non-ASCII characters are written directly in UTF-8 without encoding: FN:Muller (with the actual u-umlaut character). The ENCODING parameter is only used for binary data (ENCODING=b for Base64).

vCard 4.0 mandates UTF-8 exclusively. No other character encoding is permitted, and neither CHARSET nor ENCODING parameters are allowed for text values. All non-ASCII characters are written directly. This eliminates encoding ambiguity entirely but means vCard 4.0 files cannot represent contacts in legacy encodings without first converting to UTF-8. For more on encoding issues, see our VCF encoding error guide.

Parameter Syntax

The way parameters are written on property lines changed significantly between versions.

vCard 2.1 uses bare parameter values without a parameter name prefix. A mobile phone number is written as TEL;CELL:+1-555-100-2000. The parameter name (TYPE) is implied. Multiple types are separated by semicolons: TEL;WORK;VOICE:+1-555-200-3000.

vCard 3.0 requires the TYPE= prefix: TEL;TYPE=CELL:+1-555-100-2000. Multiple types use comma separation within a single TYPE parameter: TEL;TYPE=WORK,VOICE:+1-555-200-3000. This is a breaking syntax change from 2.1, although most parsers handle both forms for compatibility.

vCard 4.0 continues using TYPE= prefixes but adds the VALUE parameter for declaring data types. Phone numbers become TEL;TYPE=CELL;VALUE=uri:tel:+1-555-100-2000, where VALUE=uri indicates the value is a URI rather than plain text. The “tel:” prefix on the number is part of the URI format specified by RFC 3966.

Properties: What Each Version Supports

Each version supports a core set of properties while adding or deprecating others.

All three versions support the essential contact properties: FN (formatted name), N (structured name), TEL (phone), EMAIL (email), ADR (address), ORG (organization), TITLE (job title), NOTE (notes), URL (website), and BDAY (birthday). These properties work across versions with only syntax differences in how they are written.

vCard 3.0 added several properties not present in 2.1: NICKNAME (nicknames and aliases), CATEGORIES (contact grouping tags), SORT-STRING (collation key for sorting), CLASS (access classification: PUBLIC, PRIVATE, CONFIDENTIAL), and PRODID (identifies the software that created the file). It also formalized PHOTO and LOGO as standard properties with defined encoding rules.

vCard 4.0 added properties that enable richer contact representation: KIND (individual, group, organization, or location), GENDER (biological sex and gender identity), ANNIVERSARY, RELATED (relationship to other contacts), LANG (spoken languages), EXPERTISE, HOBBY, INTEREST, ORG-DIRECTORY, and MEMBER (for group vCards). It deprecated AGENT, LABEL, CLASS, and SORT-STRING from earlier versions.

Photo and Media Handling

How contact photos are stored changed in each version, and this difference causes many import failures.

vCard 2.1 embeds photos using the PHOTO property with ENCODING=BASE64 and TYPE indicating the image format: PHOTO;ENCODING=BASE64;TYPE=JPEG: followed by the Base64 data. A blank line after the Base64 data signals the end of the photo value. This blank-line termination is unique to vCard 2.1 and is a common parsing pitfall.

vCard 3.0 uses ENCODING=b instead of ENCODING=BASE64: PHOTO;ENCODING=b;TYPE=JPEG:. The photo ends when the next property begins (no blank-line termination). The value “b” is a shorthand defined specifically by vCard 3.0. Line folding (continuation lines starting with a space) handles the multi-line Base64 data.

vCard 4.0 removes the ENCODING parameter entirely for photos. Inline photos use a data URI: PHOTO:data:image/jpeg;base64,/9j/4AAQ.... Alternatively, photos can reference an external URL: PHOTO;MEDIATYPE=image/jpeg:https://example.com/photo.jpg. The MEDIATYPE parameter replaces the TYPE parameter used in earlier versions. Google Contacts uses the URL form when exporting vCard 4.0.

Addresses, Phones, and Type Labels

Address handling is structurally identical across all three versions: the ADR property always has seven semicolon-separated components (PO Box, Extended Address, Street, City, Region, Postal Code, Country). The difference is in how type labels are written. In vCard 2.1: ADR;HOME:;;42 Oak Lane.... In vCard 3.0: ADR;TYPE=HOME:;;42 Oak Lane.... In vCard 4.0: ADR;TYPE=home:;;42 Oak Lane... (lowercase types are preferred in 4.0).

Phone type labels expanded across versions. vCard 2.1 defines HOME, WORK, CELL, FAX, PAGER, and VOICE. vCard 3.0 adds MSG and PCS. vCard 4.0 adds TEXT (for text-capable numbers) and replaces PREF with the PREF parameter as a numeric value (TEL;TYPE=CELL;PREF=1:) rather than a simple flag. This means “preferred number” is expressed differently in each version.

Features Only in vCard 4.0

KIND property defines what the vCard represents. The value “individual” (default) is a person. “Group” represents a contact group with MEMBER properties listing each member. “Org” represents an organization. “Location” represents a physical place. This allows vCards to represent things other than people for the first time.

RELATED property links contacts to each other: RELATED;TYPE=spouse:urn:uuid:f81d4fae-7dec.... This enables modeling of relationships (spouse, child, parent, colleague) between vCards, useful for CRM and family contact management.

XML and JSON representations are standardized alternatives. xCard (RFC 6351) is the XML format and jCard (RFC 7095) is the JSON format. Both represent the same data as a standard vCard but in formats that are easier to process with web technologies. For more on the JSON format, see our VCF to JSON conversion guide.

Full Comparison Table

Which Platforms Export Which Version

Samsung’s continued use of vCard 2.1 is the most common reason users encounter quoted-printable encoding issues. If you export contacts from a Samsung phone and import them into Google or iCloud, names with accents or non-Latin characters may appear garbled because the receiving platform expects UTF-8 but receives QP-encoded Windows-1252 data.

Which Version Should You Use?

For sharing contacts across platforms: vCard 3.0. It is the default export format for the majority of platforms, uses UTF-8 by default, and is supported by every modern contact application. Compatibility issues are minimal.

For developer applications and APIs: vCard 4.0. The mandatory UTF-8 encoding eliminates charset ambiguity, the additional properties (KIND, RELATED, GENDER) support richer data models, and the jCard JSON format integrates naturally with web applications.

For legacy system integration: vCard 2.1. If you are working with older email clients, enterprise systems, or Samsung devices that only produce vCard 2.1, converting to a newer version may lose the CHARSET metadata that those systems rely on. Keep 2.1 for the legacy workflow and convert to 3.0 only when importing into modern platforms.

Frequently Asked Questions

Can I mix vCard versions in the same file?

Yes. A multi-contact VCF file can contain contacts with different VERSION values. Each contact declares its own version independently. Parsers should handle each contact according to its declared version. However, some applications assume all contacts use the same version as the first contact, which can cause parsing errors for mixed-version files.

Why does Outlook export vCard 2.1 instead of 3.0?

Older versions of Outlook (2016 and earlier) defaulted to vCard 2.1 for backward compatibility with Exchange Server. Newer versions of Outlook 365 and Outlook for web export vCard 3.0. The desktop client’s default depends on the version and configuration.

Does vCard 4.0 support everything from 2.1 and 3.0?

vCard 4.0 supports all commonly used properties from earlier versions but deprecated some rarely used ones: AGENT (embedded vCard for a representative), LABEL (formatted address text), CLASS (access control), and SORT-STRING (replaced by SORT-AS parameter). In practice, the deprecated properties are rarely encountered in real-world files.

Is there a vCard 5.0 in development?

As of February 2026, there is no vCard 5.0 specification in development at the IETF. vCard 4.0 remains the latest standard. Extensions to vCard 4.0 are published as separate RFCs when needed rather than as a full version increment.

Which version preserves the most contact data?

vCard 4.0 supports the most properties and the richest data model. However, preservation depends on both the exporting and importing platforms. A vCard 4.0 file with KIND, GENDER, and RELATED properties will lose those fields when imported into a platform that only supports vCard 3.0 properties. For maximum data preservation during transfer, match the version to the target platform’s capabilities.

Conclusion

Last verified: February 2026. Version syntax verified against RFC 6350 (vCard 4.0), RFC 2426 (vCard 3.0), and the Versit vCard 2.1 specification. Platform export versions tested with Google Contacts, iCloud, Outlook 365, Samsung Galaxy S24, iPhone 16, and Thunderbird 128.

The three vCard versions differ in encoding (QP with CHARSET in 2.1, assumed UTF-8 in 3.0, mandatory UTF-8 in 4.0), parameter syntax (bare types in 2.1, TYPE= prefix in 3.0, VALUE= additions in 4.0), photo handling (BASE64 with blank-line termination in 2.1, ENCODING=b in 3.0, data URIs in 4.0), and available properties (basic in 2.1, NICKNAME/CATEGORIES added in 3.0, KIND/GENDER/RELATED added in 4.0). For most users, vCard 3.0 offers the best balance of features and cross-platform compatibility.