Sustainability of Digital Formats: Planning for Library of Congress Collections

Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact
Format Description Categories >> Browse Alphabetical List

Virtual Card Format (vCard)

>> Back
Table of Contents
Format Description Properties Explanation of format description terms

Identification and description Explanation of format description terms

Full name Virtual Card Format (vCard)

Virtual Card Format (vCard) is a versatile data format designed for exchanging electronic representations of contact information. vCard is commonly referred to as an "electronic business card" and is fully and openly standardized through IETF RFC 6350. The vCard file contains the same type of content typically found on a physical business card, such as a contact’s name, address, phone number and email but may also list more personal data such as birthday or even organizational data such as line of supervision. Being digital, vCards can contain graphics (including headshots or ID photos), video, and audio as well as textual data. These files are shared across a wide variety of communication channels including email, instant messaging, text messaging, and website embedding. A single vCard file can contain information for one or more contacts. These digital cards are versatile, extending beyond personal descriptions to potentially represent various directory objects, including organizations, departments, or even buildings. However, the predominant use remains the representation of individuals.

vCards can be generated manually, stored as files, or more commonly, created by directory services like X.500 or Lightweight Directory Access Protocol (LDAP) servers.


According to David Woods in Programming Internet Email, vCard follows a straightforward structure composed of key-value pairs. It commences with a BEGIN keyword indicating the format and concludes with a corresponding END keyword. The version number is included, specifying the format used. Each piece of information in the vCard is represented by its own keyword. Custom tags can be added by applications, prefixed with "x-" as per the specification RFC 6350 Section 6.10. While parsing vCards, whitespaces are disregarded. Semicolons, when used within the text, need to be escaped with a backslash, particularly in properties like N and ADR.

vCard's content entity must initiate with the BEGIN property set to "VCARD," and the value is case-insensitive. While traditionally vCards conclude with "END:VCARD," the specification for Version 2.1 does not mandate this, making it optional. However, for Version 3 and above, "END:VCARD" became a requirement.

vCard supports the embedding of images and sound files using the MIME encoding standard. Sections 6.2.4 and 6.7.5 of the specification outline the requirements for images and sounds, respectively.

Originally known as "The Electronic Business Card". The 'v' in vCard stands for 'Versit' or 'virtual'. The terms Virtual Contact File and Virtual Card Format are used by some sources, but neither is official and is not referenced in the specification.

Refer to Phil Harvey’s “ExifTool vCard Tags” for a comprehensive list of vCard tags.

Production phase Initial state, middle state, and end state. Used to exchange information.
Relationship to other formats
    Affinity to vCalendar. Sibling specification for sharing calendars. Defined in the vCard specifications RFC 2445, RFC 2426, and RFC 2447. Not documented at this time.
    Affinity to iCal, iCalendar Electronic Calendar and Scheduling Format. The iCal format is based on vCalendar, which shares a relationship with vCard.
    Affinity to jCard. The JSON format for vCard. Defined in the vCard specification RFC 7095. Not documented at this time.
    Affinity to xCard. XML format for vCard. Defined in the vCard specification RFC 6351. Not documented at this time.
    Affinity to hCard. HTML format for vCard. See: Not documented at this time.
    Affinity to NSF, Lotus Notes Storage Facility. The Lotus Notes Storage Facility database file can save contacts in the vCard format.

Local use Explanation of format description terms

LC experience or existing holdings As of early 2024, the Library of Congress has about 35 GB of vCard files in its collections.
LC preference See the Library of Congress Recommended Formats Statement for format preferences for email.

Sustainability factors Explanation of format description terms

Disclosure Fully documented. Open specification. Standardized through the Internet Engineering Task Force (IETF).

vCard is fully documented in RFC 6350 and its antecedents, RFC 2425, RFC 2426, and RFC 4770.

See Format Specifications for a list of related specifications.


vCard has been widely adopted since the mid-1990s and has support from many major companies including: Apple, Claris, Four11, IBM, Lotus Development, Lucent Technologies, NetManage, Siemens, Google, and Novell.

    Licensing and patents

Rights to vCard were held by the Versit Consortium until December 1996 when they were transferred to the Internet Mail Consortium (IMC). IMC held the rights until 2004 when they transferred to CalConnect.


Files primarily consist of key-value pairs and can be read using a text editor. Relatively easy to decipher and does not require specific tools to get information from the files with the exception of images which will not appear in a text editor.

To use and replicate as intended to be used, within email systems, would require advanced development work.


Information can be perceived through the key-value pairs:

"A vCard consists of a list of name-value pairs. It begins with a BEGIN keyword, which names the format, and ends with a matching END keyword. The version number of the format used is included … Each piece of information to be presented has its own keyword".

vCard announces itself in the first line with "BEGIN:VCARD" and announces its version on the second line with the VERSION tag.

External dependencies None.
Technical protection considerations None.

Quality and functionality factors Explanation of format description terms

File type signifiers and format identifiers Explanation of format description terms

Tag Value Note
Filename extension vcard
See: and RFC 6350.
Internet Media Type text/vcard
See: and RFC 6350.
Internet Media Type text/directory
Not listed in IANA. See:
Internet Media Type text/x-vcard
Not listed in IANA. See:
Magic numbers See note.  All PRONOM entries state that vCard has magic numbers, however, this in not confirmed from the vCard specification. Comments welcome.
Uniform Type Identifier (Mac OS) public.vcard
Pronom PUID fmt/395
General PRONOM entry. See:
Pronom PUID fmt/1879
vCard Version 2.1. See:
Pronom PUID fmt/1880
vCard Version 3.0. See:
Pronom PUID fmt/1881
vCard Version 4.0. See:
Wikidata Title ID Q305941
Wikidata Title ID Q105859726
Other NF00432
NARA File Format Preservation Plan ID. See:

Notes Explanation of format description terms


vCard Origins and Evolution

vCard was initially created by Versit in 1990 as part of a global initiative founded by Apple Computer, AT&T, IBM, and Siemens. Over the years, the ownership and distribution of vCard technology transitioned to the Internet Mail Consortium (IMC) in 1996. At that time, the Versit Consortium, responsible for vCard, was disbanded, and IMC inherited the intellectual property. CalConnect gained rights to vCard in 2006.

vCard 4.0 and CalConnect's Role

In 2007, CalConnect hosted an open workshop, addressing existing issues and paving the way for a revision of vCard. The IETF took on the task, resulting in vCard 4.0, which addressed concerns raised during the workshop while maintaining compatibility with its predecessor. CalConnect, initiated in 2004, has played a crucial role in managing vCard standards since version 3.0. Its contributions are published through IETF RFCs for open adoption.


The primary standardized versions of vCard are 2.1, 3.0, and 4.0.

Version 2.1

Unlike Version 3.0, Version 2.1 is not an Internet proposed standard, yet it boasts widespread implementation. Version 2.1 is different from 3.0 in four ways:

  • 1. The VERSION, N, and END properties are all optional.
  • 2. TYPE keyword is not used. Any data is listed after the property value.
  • 3. The QUOTED-PRINTABLE encoding option exists. See Wikipedia for more details on this encoding option.
  • 4. BASE64 is used instead of the shorthand “b” as an encoding type.

Version 3.0

Version 3.0 differs from Version 2.1 in two ways:

  • 1. Version 3.0 contains the ability to extend types by utilizing sub-types. These are then followed by a list of more detailed parameters.
  • 2. This version also includes a REV type that specifies when the vCard was updated.

Version 4.0

The Calendar and Scheduling Consortium (CalConnect) led standardization work on Version 4.0. Appendix A of Version 4.0’s specification lists these changes as:

  • standardized properties to support modern businesses and use cases
  • independent MIME type designated for vCard usage as a standalone file
  • a standardized method of extending the vCard standard without modifying its core
  • standardized measures aimed to resolve incompatible vendor-specific properties used by client implementations
  • simplification of the vCard data format and resolution of previous inconsistencies

Format specifications Explanation of format description terms

Useful references


Last Updated: 02/28/2024