vCard (.vcf) Viewer

Paste the contents of a vCard .vcf file and read the contacts inside it as tidy cards instead of raw BEGIN:VCARD text. The viewer splits multiple cards, unfolds wrapped lines, and reads the formatted name, structured name parts, organization, job title, phone numbers and email addresses with their type labels, postal address, website, birthday, and notes. It understands both the vCard 3.0 and 4.0 ways of writing parameters, so contacts exported from phones, mail clients, or address books all read correctly. Everything runs in your browser — no contact data is ever uploaded.

How to use the vCard (.vcf) Viewer

Export a contact or a whole address book as a .vcf file, open it in a text editor, and paste the contents into the box — or load the file directly with the picker. The viewer parses it right away and shows one card per contact. A single .vcf file often holds many vCards back to back, and the viewer separates them on each BEGIN:VCARD … END:VCARD boundary, so an entire exported address book renders as a list.

For each contact it shows the display name (the FN property, or the structured N parts assembled into a name when FN is absent), the organization and job title, every phone and email with its type label such as cell, work, or home, the postal address, website, birthday, and any note. Folded long lines are rejoined first, and the two parameter styles you will encounter are both handled: vCard 3.0 writes types as TEL;TYPE=CELL or the shorthand TEL;CELL, while vCard 4.0 uses lowercase like TEL;TYPE=cell and may attach a PREF ranking. The viewer normalizes these so the labels read the same regardless of which app produced the file.

vCard: the contact-exchange standard

A vCard is the universal format for a digital business card. When you share a contact from a phone, attach a signature card to an email, or scan a QR code on someone's badge, the data travels as a vCard — a small block of plain text bounded by BEGIN:VCARD and END:VCARD. Because it is an open standard supported by virtually every phone, mail client, and address book, a contact created on one device imports cleanly into another, which is exactly the interoperability a proprietary format could never guarantee.

Three versions are in common circulation, and they differ enough that a reader must cope with all of them. Version 2.1, the oldest, often writes parameters bare, like TEL;HOME;VOICE:, and may encode values in quoted-printable. Version 3.0, standardized in RFC 2426, made TYPE= explicit, so the same number becomes TEL;TYPE=HOME,VOICE:. Version 4.0, defined in RFC 6350, modernized the format: parameters are lowercase, preference is expressed with PREF=1, and new typed properties were added. The VERSION property near the top of each card tells you which set of rules applies.

The properties themselves are rich. FN is the formatted display name and N is the structured name split into family, given, additional, prefix, and suffix parts separated by semicolons. ORG and TITLE carry the company and role, TEL and EMAIL carry contact points with TYPE parameters such as cell, work, home, or fax, ADR holds a structured postal address, and URL, BDAY, PHOTO, and NOTE round out the record. Long values fold across lines under the same 75-octet rule iCalendar uses, and text fields escape commas, semicolons, and newlines. Understanding that structure is what lets you read, debug, or migrate contact data confidently.

Common use cases

• Inspect a shared contact. Read every field of a .vcf someone sent you before importing it into your address book.
• Audit an export. Skim a full address-book export to find duplicates, missing emails, or malformed entries.
• Debug a generated vCard. Verify that software producing contact cards writes correct FN, TEL, and ADR values.
• Check a QR-code card. Decode the vCard text behind a contact QR and confirm what it actually contains.
• Migrate contacts privately. Review contact data locally when moving between phones or services, without uploading it anywhere.