vCard QR code generator

vCard 4.0 has been the standard since 2011 and is better in every technical respect. It is also read unevenly: iOS handles it, a good deal of Android does not, and neither do several address-book imports that people paste these into. 3.0 has been read by essentially everything since 1998.

That is the whole argument. A contact card is only useful if it opens, and the cost of being one version behind is a handful of fields nobody puts on a business card anyway. If you are generating cards for a system you control and know reads 4.0, a different tool is the right choice; for a card handed to a stranger, 3.0 is.

A vCard carries the name twice: `FN` is what gets displayed, and `N` is the structured form — surname, given name, middle, prefix, suffix. Both are required in 3.0, and some parsers reject a card without `N` outright rather than falling back to `FN`.

This page fills `N` by splitting on the last space, which is right for most European names and wrong for plenty of others — a compound surname, a name written family-first, a mononym. Getting it wrong affects how the contact sorts in the address book and nothing else, whereas leaving it out risks the card not importing at all. It is the lesser of two imperfect options and it is worth knowing which one you got.

RFC 6350 requires lines longer than 75 octets to be split, with each continuation beginning with a single space that the parser strips. Most phones tolerate an unfolded long line; "most" is the problem, because the failures are on older Android builds and in some CRM imports, and they are silent.

The limit counts bytes, not characters, which matters as soon as a name is not ASCII: a name in Devanagari reaches 75 bytes in about 25 characters. Splitting inside a multi-byte character would corrupt it, so the break here walks back to a character boundary — the kind of detail that only shows up as a mangled name in somebody else’s phone.

A number stored as `020 7946 0000` is only dialable from inside that country, and a contact card is exactly the object most likely to cross a border. Written as `+44 20 7946 0000` it works from anywhere, and every phone strips the spaces before dialling.

The `+` matters more than the formatting. Phones treat a leading plus as "the country code follows" and substitute whatever prefix the local network needs, which is `00` in most of the world and `011` from North America. Without it a number that looks complete simply fails to connect, and the person scanning has no way to guess what is missing.

A vCard is verbose — property names, type parameters, line breaks — so a card with five filled fields is already a few hundred bytes, which puts the code around version 8 or 9. That is fine on a screen and marginal on a business card printed at two centimetres.

If the code is going somewhere small, the fix is fewer fields rather than a smaller code: name, one phone number and one email will scan from a card that a full card with an address will not. And if you need the address and the job title and the second number, put a URL in the code instead and let the page carry the detail.

iOS and Android both recognise a vCard payload from the camera and offer to create a contact, showing the fields first. Neither saves anything without a tap, which is the correct behaviour and worth knowing when you test — a code that "does nothing" has usually opened a prompt behind the camera view.

Where it varies is what happens with a contact that already exists. Some versions offer to merge and some create a duplicate, and there is no field you can add to control it. That is a reason to test the card you actually printed on a phone that already has you in it, which is the case for most people who will scan it.

The details are inside the pattern. Change your phone number and every printed card carries the old one for as long as the cards exist, which for a conference badge is a week and for a business card can be years.

The alternative is a URL to a page you control, which stays current and gives you the option of updating it — at the cost of needing the network, and of the page needing to exist for as long as the cards do. Neither is right in general. A card handed out at one event is better as a vCard; a card that will sit in wallets for two years is usually better as a link.

The vCard is assembled and encoded in this page. Your name, number and address are not sent anywhere, and the network panel shows that during use.

This is a page whose entire input is personal data — a name, a phone number, an email address, all belonging to a real person and frequently to a colleague rather than to you. A generator that builds the image on a server has received all of it, and under most data-protection regimes that is a transfer you would have to account for. Here there is nothing to account for, because nothing moved.