A contact QR code carries a whole vCard — name, company, job title, phone, email, website and a structured postal address — as text inside the pattern. Scanning it offers to save the contact. No app, no account, and nothing to keep paying for.
Make a contact QR code → MeCard instead →
vCard’s ADR is not free text. It is a positional value with seven components separated by semicolons, and the position is the only thing that says which field is which:
ADR;TYPE=WORK:;;120 High Street;Springfield;IL;62704;USA
| Slot | Component | In the example |
|---|---|---|
| 1 | Post office box | (empty — deprecated) |
| 2 | Extended address | (empty — deprecated) |
| 3 | Street | 120 High Street |
| 4 | Locality / city | Springfield |
| 5 | Region / state | IL |
| 6 | Postal code | 62704 |
| 7 | Country | USA |
Generators that give you one box labelled “Address” put everything into slot 3 and leave the rest empty. The card still imports, which is why the mistake survives — but the contact arrives with a street line reading 120 High Street, Springfield, IL 62704, USA and no city, region, postcode or country at all. Sort by city later and that contact is not in the list.
This tool asks for the five parts separately and writes all seven slots. We had the one-box version ourselves until we checked it against the specification, which is a fair warning about how easy it is to get wrong.
Both encode a contact; they are different formats with different trade-offs, and the right answer depends on who is scanning.
| vCard | MeCard | |
|---|---|---|
| Fields | Everything above, plus a structured address | Name, phone, email, website |
| Size | Longer — more modules, denser code | Shorter — a smaller, coarser code |
| iPhone | Reliable | Patchy |
| Android | Reliable | Native |
Pick vCard unless you have a specific reason not to. MeCard’s advantage is that it makes a physically smaller code, which matters when the code has to fit in a corner of a card and the payload is long.
This is the practical question, and it has a real answer. A full vCard is a lot of text, so the code has many more modules than a link does — and more modules in the same square means each one is smaller. The usual rule is that a module should not fall much below 0.4 mm.
| Printed width | A short link (25 modules) | A typical contact card |
|---|---|---|
| 15 mm | 0.65 mm per module | uncomfortably fine |
| 20 mm | 0.61 mm | about the practical floor |
| 25 mm | 0.76 mm | the size to aim for |
| 30 mm | 0.91 mm | comfortable, if the card has room |
The panel under the preview does this sum for the card you actually build, because the module count depends entirely on how much you put in. If it comes out too dense for the space, the fix is to carry less: a phone number and an email will scan from a much smaller square than a full postal address will.
Print from the PDF or EPS. Both are true vectors, so the print shop can place the code at whatever size the layout needs without a single soft edge — and soft edges are exactly what a scanner struggles with at this size.
A logo in the middle of a contact code is a popular request and a risky one, because a contact card is already a long payload. We swept a centre block across payload lengths and error-correction levels: at level H the largest logo that still read back covered 15.2% of the code’s area on a long payload — nowhere near the 30% that level is named for, because recovery counts codewords spread across the symbol while a logo destroys one solid block.
There is no size that is safe in general, which is why the tool does not print one. It decodes your actual code, with your actual logo, and tells you whether your details came back before you download it.
The address is the trap people notice. The name is the one they do not, because it goes wrong quietly. A vCard carries the name twice, for two different purposes:
N:Okonkwo;Ada;;;FN:Ada Okonkwo
N is structured and positional, like the address — surname, given name, middle names, prefix, suffix, in that order. It is what an address book sorts and searches on. FN is the display name, free text, and it is what you see at the top of the contact. Write only FN and the card imports with nothing to sort by; write N with the parts the wrong way round and every phone in the room files you under your first name.
This tool asks for given and family name separately and writes both fields, in the right order, from the same two boxes. It is the same lesson as the address: a single “Name” box cannot produce a correct vCard, however tidy it looks in the form.
Worth knowing if your name is not spelled in ASCII, because the obvious assumption is wrong. Accents do not make the code meaningfully bigger; length does. The same card with four different names:
| Name | Payload | Modules across |
|---|---|---|
| Ada Okonkwo | 133 bytes | 49 |
| Jürgen Müller | 141 bytes | 49 |
| Γιώργος Παπαδόπουλος | 189 bytes | 57 |
| 田中 太郎 | 137 bytes | 49 |
Two umlauts cost four bytes and change nothing. The Greek name jumps the code from 49 modules to 57 — not because Greek is expensive, but because that name is 19 characters and each one costs two bytes. The Japanese name costs three bytes per character and still lands at 49 modules, the same as the plain Latin one, because it is only 4 characters long. Character count matters more than the script.
The practical consequence is only that a long name in a two-byte script wants a slightly larger printed code. Nothing needs escaping or transliterating: the text is encoded as UTF-8 and comes back exactly as typed, accents and all. Some older generators quietly mangle this — a well-known library prepends a byte-order mark to any non-ASCII string, so the name that scans back is not the name you entered.
Yes — and you almost certainly should not. Both halves of that are worth spelling out, because the usual answer online is a flat “it will not fit”, and we measured that to be wrong.
vCard has a PHOTO field that carries the image itself, base64-encoded, inside the payload. We built real cards with a real JPEG avatar at several sizes and read every one back with both decoders. A 128 px portrait encodes and scans perfectly well. The problem is what it does to the pattern:
| Photo | Modules across | Module size at 25 mm |
|---|---|---|
| None | 57 | 0.39 mm |
| 48 px (0.9 KB) | 133 | 0.18 mm |
| 96 px | 157 | 0.15 mm |
| 128 px | 169 | 0.14 mm |
A thumbnail so small you would struggle to recognise the face takes the same card from 57 modules across to 133 — because base64 inflates the image by a third before it is encoded, and the QR code then has to carry all of it. In the same printed square each module shrinks from 0.39 mm to 0.18 mm, which is well under the 0.4 mm floor that printing and scanning both start to fail at. To hold that photo and stay printable you would need a code several times the size of the card it is going on.
There is a second reason, less obvious and more annoying in practice: many address books ignore a PHOTO arriving this way, so a good proportion of the people who scan your card get the enormous code and no picture at all. The photo is paid for on every scan and delivered on some of them.
What works instead is a URL pointing at a page with your photo on it — a few dozen characters rather than a couple of thousand. The contact saves instantly, the code stays small enough to print on a card, and the picture is a tap away for anyone who wants it.
One note on the numbers above: even with no photo at all, a full card with a postal address lands at 0.39 mm per module at 25 mm, which is already at the edge. If you are carrying the complete address, give the code 30 mm rather than 25.
Your details are encoded into the pattern itself. There is no short link, no redirect and no account, so the code cannot be switched off, and no one collects a list of who scanned your card. Services that offer an editable “digital business card” work the other way: the code points at their server, which is what makes the destination changeable and the scans countable — and what makes the card stop working when the subscription does.
The trade is real and worth stating plainly: a static card cannot be re-pointed after it is printed. If your number changes, you print new cards, exactly as you would have before QR codes existed.
Making it is private too. Your name, phone number and home or office address are turned into a pattern by code running in your own browser — the page has no fetch, no XMLHttpRequest and no form, so there is nothing that could send them anywhere. For personal contact details that is worth more than it sounds.