Download Sample VCARD Files

A vCard (Virtual Business Card) is a standard file format for storing and exchanging contact information. Files use the .vcf extension (vCard Format) and contain structured plain text with labelled property fields — name, phone numbers, email addresses, postal addresses, photos, and more. The format was originally created by Versit Consortium in 1995 and is now governed by the IETF.

vCards are the universal import/export format for contacts across platforms. When you tap "Share Contact" on iPhone, export a contact from Google Contacts, or send a business card via QR code, the underlying file is almost always a .vcf. Every major address book application — iOS Contacts, macOS Contacts, Android, Outlook, Thunderbird, Gmail, and Salesforce — can import and export them.

vCard 2.1 is the original version, created before the IETF was involved. It requires an explicit CHARSET parameter on properties that use non-ASCII text, and uses ENCODING=BASE64 for binary data (like photos). It remains supported by many legacy devices but lacks modern fields entirely.

vCard 3.0, defined in RFC 2426, cleaned up the format somewhat, switching photo encoding to ENCODING=b and becoming the most widely deployed version across iOS, macOS, Android, and Outlook. It still does not support social profiles or the KIND property natively.

vCard 4.0, defined in RFC 6350, assumes UTF-8 encoding throughout (no more CHARSET parameters), adds KIND (individual, org, group), GENDER, SOCIALPROFILE, RELATED, CALURI, and several other modern fields. It also unifies how URIs, data URIs, and text values are expressed. vCard 4.0 is the best choice for new tooling, but 3.0 has the widest real-world app support as of 2024.

Yes. A .vcf file can contain any number of individual vCard blocks, each delimited by BEGIN:VCARD and END:VCARD. Most address book applications handle multi-contact files gracefully — for example, Apple Contacts will prompt you to import all N contacts at once. Some parsers, particularly in mobile apps, may only read the first card, so it is worth testing with your specific target application when building tooling.

Google Contacts' import UI explicitly lists how many contacts it found in the uploaded file before asking you to confirm. The samples in the multi-contact cards on this page use 5, 10, and 25 contact blocks to cover common ranges for import/export testing.

The absolute minimum for a valid vCard across all versions is: BEGIN:VCARD, a VERSION property, at least one FN (formatted name) property, and END:VCARD. RFC 6350 (vCard 4.0) formally requires FN to be present; in practice, most parsers will also accept N (structured name) as a substitute. The N property itself is technically required in 3.0 but optional in 4.0.

In reality, a vCard with only FN is valid but not very useful. For a realistic minimal card you would typically include FN, N, at least one TEL or EMAIL, and UID so the contact can be deduplicated on import.

The most common library is vobject: pip install vobject. Parse a file with import vobject; cards = list(vobject.readComponents(open('contacts.vcf').read())). Access the formatted name with cards[0].fn.value, iterate phone numbers with for tel in cards[0].contents.get('tel', []): print(tel.value). The library handles all three vCard versions and gracefully degrades on unknown properties.

An alternative is py-vcard or parsing the text manually — vCard is newline-delimited plain text so a simple dict builder works for basic use cases. For production code, prefer vobject since it handles line folding (long property values that wrap at 75 characters) and base64-encoded photo data correctly.

The vCard specification requires that lines longer than 75 octets be "folded" — split across multiple lines where each continuation line begins with a single whitespace character (a space or tab). This is the same mechanism as MIME header folding. For example, a long PHOTO base64 value or a long ADR field would appear in a file with the second and subsequent physical lines beginning with a space, which parsers then join back into one logical line by stripping that leading whitespace.

Line folding trips up naive string-splitting parsers. If you split a .vcf on newlines and process each line independently, you will break folded values into garbage. Correct parsing requires reassembling logical lines first — look for continuation lines starting with whitespace and concatenate them to the previous line (minus the leading whitespace) before processing property names and values.

In vCard 4.0, you can reference a photo by URI: PHOTO:https://example.com/avatar.jpg, or embed it as a data URI: PHOTO:data:image/jpeg;base64,/9j/4AAQ.... The data URI approach makes the vCard self-contained but produces large files.

In vCard 3.0, the syntax is slightly different: PHOTO;ENCODING=b;TYPE=JPEG:/9j/4AAQ... (the ENCODING=b signals base64, the value is just the raw base64 without the data URI wrapper). vCard 2.1 uses PHOTO;ENCODING=BASE64;TYPE=JPEG: followed by the base64 data on continuation lines. For test purposes, the samples on this page that include a photo embed a tiny 1×1 pixel JPEG data URI so the file stays small but exercises the photo field path in parsers.