vCard QR codes — the digital business card

A vCard QR code does exactly what business cards have been promising for thirty years: someone meets you, they want your contact details, and the details land in their phone correctly the first time. No typos, no follow-up email asking for your number, no "I'll add you on LinkedIn" that never quite happens.

The technology is unglamorous and works almost everywhere. iOS, Android, and most modern devices all parse vCard format natively. Scan a vCard QR code and you get a "Add to contacts" prompt instantly. No app required.

This post covers what a vCard actually is (it's older than you think), how to encode one into a QR code, what the format does well, where it falls short, and the small set of fields you actually want.

What a vCard is#

vCard is a text file format defined by the IETF in 1996 (RFC 2425, then 2426, then 6350). It's how every contacts app under the sun stores entries. When you tap "share contact" on iPhone or Android, you get a .vcf file — that's a vCard.

A minimal vCard looks like this:

BEGIN:VCARD
VERSION:3.0
N:Doe;Jane
FN:Jane Doe
ORG:Linked.Codes
TEL;TYPE=CELL:+62-812-3456-7890
EMAIL:jane@linked.codes
URL:https://linked.codes
END:VCARD

That's the whole format. Field names, colon, value. Multi-line. Some fields have type modifiers (TEL;TYPE=CELL vs TEL;TYPE=WORK). The version line at the top tells parsers which spec to apply — 3.0 is the safe default, 4.0 is newer and adds a few fields but isn't supported as broadly on older phones.

A vCard QR code encodes that whole text block into the QR's data area. Scan it on any modern phone and the OS recognises the format and offers to add it as a contact.

vCard format is older than the iPhone, older than Gmail, older than the public web in any practical sense. The reason it still works is the reason it was designed: every contacts app speaks it natively.— RFC 2425, July 1996

Why vCard beats a "scan to email me" code#

Three things vCard does that a plain email or website link can't:

Multiple fields at once. A scan-to-email code gives someone your email. A vCard gives them your full set — name, number, email, website, job title, organisation. They get to choose which fields to keep.

Native OS handling. iOS and Android both have built-in vCard parsing. The user doesn't visit a webpage; the contact card opens directly in their contacts app. No tracking, no JavaScript, no waiting for a server.

Works offline. A vCard QR code is static — the data lives in the print. No internet connection needed to scan, parse, and save.

Travels well. A vCard QR code on a poster at a conference works for someone who doesn't speak the local language. They scan, the contact card appears in their language, the fields are labelled by their phone's OS.

The trade-off: it's static. Change your phone number and every printed vCard QR code is wrong. Some businesses solve this by encoding a URL to a hosted vCard file — that converts the static format into a dynamic one (with the same lookup-server caveat as any dynamic QR).

The fields that matter (and the ones that don't)#

vCard 3.0 has dozens of fields. Most of them you'll never use. Here's the practical short list.

Always include:

• N: — structured name (last, first, middle, prefix, suffix). Some parsers want this, some are flexible.
• FN: — formatted name (the display name). Always present.
• TEL: — phone number. Use international format (+countrycode-...) so it works abroad.
• EMAIL: — email address.

Usually include:

• ORG: — organisation name.
• TITLE: — job title.
• URL: — website.

Add when relevant:

• ADR: — physical address (structured: PO box, extension, street, city, region, postcode, country).
• NOTE: — free-text note. Useful for "Best contact: WhatsApp" kind of context.
• PHOTO: — embedded contact photo. Usually skipped because it inflates the QR size noticeably.

Skip:

• BDAY: — birthday. Personal, rarely needed in a business contact.
• LOGO: — organisation logo. Same size problem as PHOTO.
• X-*: extension fields. Inconsistent across parsers.

The principle: every field you add makes the vCard text longer, which makes the QR code denser. A vCard QR with 8 sensible fields is sparse and scans easily. A vCard with an embedded photo is huge and won't fit on a small business card.

A live builder#

That's the actual format the QR code encodes. Open it in any text editor, save with extension .vcf, and most contacts apps will accept it as a file too.

What goes wrong#

The vCard format is forgiving but the implementations vary. Three quirks worth knowing about:

Apple's parser is stricter than Android's. iOS expects N: and FN: both present. Android tolerates either. To be safe, include both even if redundant.

Phone numbers want international format. A vCard with TEL:0812345678 works on the phone that scanned it but may not work when the contact tries to call from another country. TEL:+62-812-345-678 works everywhere.

Special characters need escaping. Commas inside a field value need to be \,. Same for semicolons, colons, and backslashes. If your job title is "Founder, CEO", the vCard should encode it as TITLE:Founder\, CEO. Most generators handle this; if you're rolling your own, don't forget.

Emoji in names mostly works but not always. Modern parsers handle UTF-8 in vCard fields. Older Android parsers and some enterprise contact systems strip non-ASCII. If your audience matters, stick to plain Latin characters.

Static vCard vs dynamic vCard#

Two ways to put a vCard behind a QR code.

Static vCard QR. The whole vCard text is encoded in the QR. Permanent, free, offline-capable. The downside: change anything and you have to reprint.

Dynamic vCard QR. The QR encodes a short link that points at a hosted vCard file (https://lnks.work/k/jane-vcard). Scanning fetches the file, the OS sees vCard format, prompts to add. You can update the file, swap fields, or move the vCard entirely without reprinting.

Static is right for personal cards you reprint anyway when you order new ones. Dynamic is right for company cards where the role might change, the phone number might rotate, or the person leaves. The dynamic version also lets you A/B-test which fields drive the most contact saves — which is a thing you can quietly measure with the right platform.

Where a vCard QR shows up#

The classic case is the back of a business card. Front: name, role, logo. Back: a QR code with a "scan to save" eyebrow. Hand it over, the recipient scans, the contact lands. They can throw away the card immediately if they want — the data's already in their phone.

Other places it works:

• Conference badges. Same logic. Less printing for the attendee, faster contact exchange than typing.
• Email signatures (as an image). Embed the vCard QR as a 200×200 PNG. The recipient scans from their other phone, contact saved.
• Door plates and reception desks. "Need to reach me? Scan." Useful for small offices where the receptionist is elsewhere.
• Restaurant tabletop service. A vCard for the restaurant ("scan to save us in your contacts"), often paired with a discount or loyalty hook.

The pattern: anywhere someone might want to keep your contact details and would otherwise have to type them.

What we ship by default#

When you generate a vCard QR code on Linked.Codes, the form has the seven sensible fields above. The vCard text is generated correctly with proper escaping. Phone numbers are validated for international format. The QR is rendered at level Q error correction, with round modules and your accent colour by default — the same renderer the rest of the platform uses.

You can also generate a dynamic vCard QR (encodes a short link, vCard file is hosted at the link). The escape hatch is the same as for any dynamic code: the link can be repointed without reprinting.