Skip to main content
QR codesvCard 3.0Nothing uploaded

vCard QR Code Generator

A contact QR code carries a vCard — a small text record the phone offers to save. This one writes vCard 3.0 with the line endings the grammar requires and without the character-set parameter that version removed. The thing to watch is length: every field you add makes the symbol denser and harder to scan from a card.

A digital business card. Scanning saves the whole contact at once.

Appearance — all of it free

Caption

Print sizing

50 cm · 20 in

Both matter. Distance decides how big the code has to look; the printer decides how small a module it can hold. Whichever asks for more is the size to print.

Your code

Fill in the fields above and the code appears here.

What is actually inside this code

A working business card. Six fields, and already a version 4 symbol — which is the constraint this format lives under.

Name
Maya Park
Company
Northline Studio
Phone
+1 555 123 4567
Email
maya.park@example.com
Website
example.com/maya

encodes as

BEGIN:VCARD
VERSION:3.0
N:Park;Maya;;;
FN:Maya Park
ORG:Northline Studio
TEL;TYPE=CELL:+15551234567
EMAIL:maya.park@example.com
URL:https://example.com/maya
END:VCARD

174 bytes — a version 9 symbol, 53 modules a side. The phone shows Maya Park as a contact, ready to save.

The example above, encoded. It scans.

Why this writes vCard 3.0 and not 4.0

vCard 4.0 has been a published standard since 2011, and picking it would look like the modern choice. For a QR code it is the riskier one. A scan is a single shot — if the card fails to parse, nobody retries, they just put the phone away.

Apple's documented contact-import API states vCard 3.0 support. The Android parser for 4.0 has carried incomplete-support warnings in its own source, and handset makers ship their own contacts apps on top of it. Neither of those is proof that 4.0 fails; both are reasons not to bet a printed card on it.

The character-set parameter that should not be there

A great many vCard generators — including, until recently, one of ours — write `FN;CHARSET=UTF-8:Maya Park`. It looks careful. It is invalid. RFC 2426 explicitly removed the property-level `CHARSET` parameter when vCard 3.0 replaced 2.1; character encoding moved up to the enclosing message. Android accepts it anyway, and says so in its source comments, because so many non-conforming files exist in the wild.

Line endings are part of the grammar too, and this is the one nobody sees. vCard properties end with a carriage return followed by a line feed, not with whichever newline the platform happens to use. It is invisible in any preview, which is exactly why a generator has to construct it deliberately rather than inherit it.

The real constraint is how much you put in it

Every line costs bytes, and bytes cost modules. The example above is a modest card — name, company, phone, email, website — and it is already a version 4 symbol at 33 modules a side. Add a job title, a second number, a postal address and a longer URL and you are at version 6 or 7 without having added anything a recipient could not have found.

That matters because a business card is small. More modules in the same printed width means each module is finer, and a phone camera has to resolve finer detail from the same distance. It is the one trade-off in this format worth understanding.

What the largest symbol holds, by error-correction level
Level L
2,953 bytes
Level M
2,331 bytes
Level Q
1,663 bytes
Level H
1,273 bytes

Version 40, the biggest symbol there is, at 177 modules a side. A contact card should not come close to any of these — if it does, the problem is the card.

Adding a logo pulls the same way, because a logo forces error correction to level H and level H holds the least data of the four. A long card and a logo together is the combination that produces a symbol nobody can scan off a business card.

Do

  • Include the fields someone would actually save: name, one number, one email.
  • Put the country code on the phone number so it dials from anywhere.
  • Test the printed card at arm’s length, which is how it will really be scanned.

Don't

  • Add a postal address, a fax number and three URLs because the fields exist.
  • Use vCard 4.0 on the assumption that newer means more compatible.
  • Shrink the code to fit the layout. Shorten the card instead.

Frequently asked questions

Why does this use vCard 3.0 rather than 4.0?

Because a QR scan gets one attempt. Apple's documented import API states 3.0 support, and the Android 4.0 parser has carried incomplete-support warnings in its own source, on top of which handset makers ship their own contacts apps. That is not proof 4.0 fails — it is a reason not to stake a printed card on it.

Should the vCard include CHARSET=UTF-8?

No. RFC 2426 removed the property-level CHARSET parameter when 3.0 replaced vCard 2.1, so it is invalid syntax in a 3.0 card. Android tolerates it only because non-conforming files are so common. Accented names survive because the QR payload is UTF-8 in the first place, which is what actually carries them.

Why is my contact QR code so dense?

Because vCard is verbose and every field adds bytes. Name, company, phone, email and website already make a version 4 symbol at 33 modules a side. Adding a title, an address and a second number pushes it higher, and a higher version means finer modules in the same printed width. Cut fields rather than shrinking the code.

Would MECARD make a smaller code?

Yes, noticeably. A representative MECARD runs about 59 bytes where the equivalent vCard 3.0 is about 107. The cost is a smaller and much less rigorously standardised data model, so it is worth it only when payload size is the binding constraint — a very small printed code, for instance — rather than as a default.

Other things a QR code can do

Every type, one tool

QR Code Generator

Colours, shapes, a logo, a caption, a print-size check and an A4 sheet — all of it free, none of it behind an account, and the code stays yours because the data is inside it rather than on our server.

Open the full QR code generator →