Search this problem and you land in forum threads rather than answers. Adobe's InDesign community, Apple's developer forums, Tom's Guide — page after page of people whose QR code scans fine, shows something, and then simply will not become a contact. The replies are mostly guesses about phone settings.
It is almost never a phone setting. A vCard is a strict little text format, and the things that break it are small, specific and diagnosable from the payload itself. What follows is the format, the failures behind nearly every report, a vCard known to be correct, and a symptom-to-cause table to work down.
Work out which of the three failures you have
Three different problems get described with the same sentence, so establish which one you have before changing anything.
The code does not scan: the camera sits on it and nothing appears. That is a QR encoding problem, and editing contact fields will not touch it.
It scans and shows raw text — BEGIN:VCARD and the rest, visible as a string. The scanner decoded the code perfectly but did not recognise the payload as contact data. That is structural, in the first or last lines.
It offers to save, but what lands is wrong: a blank name, a surname where the first name should be, an address truncated at a comma. That is field-level, and the most common of the three.
Get the decoded payload first, from any reader that shows raw text — not the generator's web form.
The VERSION line decides more than anything else
Version 2.1 declares encoding per property, typically ENCODING=QUOTED-PRINTABLE. Non-ASCII characters become escape sequences — an umlaut is written =C3=BC — and any parser that does not decode quoted-printable shows those sequences literally. This is the most reported cause of garbled names.
It also explains the most-linked thread on the subject: InDesign's QR generator emits 2.1 from its business card form, and the community's standing advice is to ignore that form, switch to plain text mode, and paste a hand-written 3.0 card instead.
Version 3.0, from RFC 2426, is the safe target. It requires BEGIN, VERSION, N, FN and END, and it is read by essentially every address book in circulation.
Version 4.0, from RFC 6350, is current and mandates UTF-8. But developers on Apple's forums report the iOS Camera app mis-decoding accented characters from 4.0 payloads, with one reply noting that 3.0 parses correctly as a workaround. That is a forum report rather than documented Apple behaviour — a strong hint, not a rule.
Whichever you use, VERSION must be the second line, immediately after BEGIN:VCARD. Several parsers will not look elsewhere.
N and FN do different jobs
N is a structured value: five components separated by semicolons, in the fixed order Family, Given, Additional, Honorific Prefixes, Honorific Suffixes. FN is a single piece of display text — the name as a person would write it.
So the correct pair is N:Okafor;Jane;;; and FN:Jane Okafor. The trailing semicolons are not padding to tidy away; they mark the empty components.
The failures are predictable. N:Jane Okafor with no semicolons puts the whole string in the family-name slot, so the contact shows a surname of Jane Okafor and no first name. FN:Okafor;Jane puts a literal semicolon in the display name.
FN is required in both versions — in 4.0 its cardinality is one or more, making it the one property you cannot omit. Leave it out and some address books synthesise a name from N, some import a blank name, some refuse the record. iOS is generally stricter here, Android more forgiving, though that varies by handset.
Line endings, folding and escaping
The spec delimits content lines with CRLF, not a bare newline. Most parsers tolerate LF-only payloads, but strict ones do not, and a generator that writes LF produces a file that looks perfect in an editor and fails silently on import.
Folding is subtler. Lines over 75 octets should be folded, and unfolding treats a CRLF followed by a single space or tab as though neither were there. A continuation line that loses its leading space becomes a nonsense property line and gets dropped — which is how a city name ends up cut in half. A fold landing mid-character destroys that character.
For a QR payload, do not fold at all. Scanners do not care, and folding only adds bytes to a code you want small.
Escaping catches people out on ordinary details. Commas, semicolons and backslashes inside a text value must each be escaped with a backslash. An unescaped comma in ORG:Reed, Okafor and Co can be read as a value separator; an unescaped semicolon in an address splits the structure at the wrong point.
A minimal vCard that is known to be correct
Start here, confirm it saves cleanly on both platforms, then add fields one at a time until something breaks. Type it with CRLF line endings, no leading or trailing whitespace, and nothing before BEGIN or after END.
- BEGIN:VCARD
- VERSION:3.0
- N:Okafor;Jane;;;
- FN:Jane Okafor
- ORG:Reed Joinery
- TEL;TYPE=CELL:+447700900123
- EMAIL;TYPE=INTERNET:jane@reedjoinery.co.uk
- URL:https://reedjoinery.co.uk
- END:VCARD
Why a long vCard stops scanning altogether
QR symbols come in forty versions, and the module count is four times the version plus seventeen. Version 10 is 57 modules a side and holds 271 bytes at the lowest error correction level, 213 at the next. Version 15 is 77 modules and holds 520 or 412. Version 40 is 177 modules and holds 2,953 or 2,331.
Count a realistic card. The example above with an address line runs to roughly 280 bytes — past version 10, landing between 10 and 15, so around sixty-five modules a side. Embed a photo as base64 and you are into the high versions, where the symbol is a dense grey mat.
A link inverts that. Thirty-five characters fits inside a version 5 symbol at 37 modules a side. At the same printed width those modules are nearly twice as wide. Denso Wave puts the minimum module pitch for reliable handheld scanning at 0.4mm — the number a small printed card quietly violates as the payload grows.
iPhone and Android do not behave the same
On iOS the Camera app handles this natively, but it can be switched off: Settings, Camera, Scan QR Codes. An update or a restored backup can leave it disabled, and the symptom is a camera that ignores the code. When it does recognise a vCard, iOS shows a banner that opens a contact preview with a save option — so a Focus mode suppressing notifications can also make it look like nothing happened.
Android has no single answer, and this is where device-specific claims deserve suspicion. Handling depends on the manufacturer's camera app, on Google Lens, or on whatever scanner is installed, and it varies by manufacturer and Android version. Lens will generally offer an add-to-contacts action for a code it recognises as contact data. Beyond that, anyone telling you exactly what a given handset does is guessing.
One thing is consistent: TYPE labels map inconsistently. A number marked CELL can land as work, home or other depending on the importing address book. That is a known rough edge, not something the payload can fix. Test on one of each platform.
The failure matrix
Work down this list. Each line is symptom, then likely cause, then fix.
- Camera ignores the code entirely — QR is too dense, or iOS QR scanning is switched off — shorten the payload or print larger; check Settings, Camera, Scan QR Codes.
- Scans, but shows raw text like BEGIN:VCARD — payload not recognised as a vCard — confirm BEGIN:VCARD is the first line, VERSION the second, END:VCARD the last, with no stray whitespace.
- Saves with a blank name — FN is missing — add an FN line with the display name.
- Name imports surname-first or with a literal semicolon — N and FN are swapped or N is unstructured — use N:Family;Given;;; and FN:Given Family.
- Name shows sequences like =C3=BC or =E4 — vCard 2.1 with quoted-printable encoding — reissue as 3.0 in plain UTF-8, removing the CHARSET and ENCODING parameters.
- Accented characters wrong on iPhone only — reported iOS Camera handling of vCard 4.0 payloads — fall back to 3.0.
- Address or company truncated at a comma or semicolon — unescaped punctuation in a text value — escape commas, semicolons and backslashes with a backslash.
- A value is cut off mid-word — line folded without the continuation space, or folded mid-character — remove folding entirely from QR payloads.
- Import fails only on older devices — payload uses 4.0 properties the parser does not know — downgrade to 3.0.
- Hosted .vcf opens as a text page instead of offering to save — server sends the wrong MIME type — serve it as text/vcard.
Encode the card, or encode a link
Once the payload is correct, one design decision is left, and it is a genuine trade-off. Encoding the vCard directly means it saves with no connection at all, which matters in basements, workshops and on aircraft. The costs: the code is dense, the data is frozen the moment you print it, and you are exposed to every parser quirk above.
Pointing at a hosted card inverts all of it. The payload is short, so the symbol is low-version and forgiving; every scanner handles URLs, so the recognition problem disappears; the page serves a properly formed .vcf with the right MIME type on tap; and a wrong number becomes a fix rather than a reprint. OneSol generates the vCard this way behind its digital business cards. The cost is that it needs signal.
If in doubt the link is the safer default, because its failure — no signal — is visible, while an encoded vCard's failures are silent and land in someone else's address book. Either way, test the real artefact: print at actual size, scan on a phone that is not yours, open the saved contact.