What you are seeing
The code scans, but the contact does not save: the phone shows nothing, shows a garbled entry, or saves a contact with missing fields. The scan worked, so the fault sits in the contact payload: the format, the field names, or a character the phone cannot parse. Contact codes come in two main formats, and a payload that mixes them or mistypes a field can fail on one platform while working on another. The fix is to decode the payload and to rebuild it in the clean standard format.
Likely causes
1.
Mixed or non-standard format — A payload that mixes two contact formats, or uses a field the phone does not recognise, can fail or save a partial entry. Test: decode the payload and compare it with the standard format.
2.
Field name the phone does not recognise — A mistyped or unusual field name can make the phone drop that field or the whole entry. Test: check each field name against the standard list.
3.
Special characters breaking the format — A comma, semicolon, or line break inside a value can break the field structure if it is not escaped. Test: try a simple contact with plain characters and compare.
4.
Too many fields for the phone to handle — A contact packed with every possible field can trip a limit or a parsing fault on some phones. Test: try a minimal contact with name and phone only.
5.
Phone permission or app handling — A phone that blocks the contacts app, or an app that handles the scan instead of the contacts app, can stop the save. Test: check whether the phone shows a save prompt at all.
Step-by-step fix
1. Decode the payload and write down every field it carries.
2. Compare the format and the field names with the standard contact format.
3. Rebuild the contact with the contact generator, using plain characters where possible.
4. Test a minimal contact first: name and phone only.
5. Add the remaining fields one group at a time and retest after each group.
6. Retest the full contact on two phones and confirm every field lands correctly.
Putting this into practice
In practice, start minimal and add fields until it breaks. A contact with name and phone that saves tells you the format works; the field that breaks the save when you add it is the culprit. That approach finds the fault faster than staring at a long payload. Keep a short note of what you tested, what failed, and what you changed, so the next person starts from evidence rather than guesswork. A fix that is written down survives staff changes and reprints; a fix that lives only in memory gets repeated.
Common mistakes to avoid
- Packing every possible field into a contact code and never testing whether it saves on a real phone.
- Reprinting the full run before a single proof passes, which turns one failure into many.
- Testing on one phone in ideal conditions instead of two phones in the real conditions where a code that scans but the contact will not save will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that scans but the contact will not save.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The payload uses the standard contact format
- A minimal contact saves on two phones
- The full contact saves with every field in place
- The corrected proof passes on two phones in the real conditions
- The fix is recorded in the job file so the next reprint starts from a proven setup
- Every printed copy is checked against the approved proof
- The proof is retested after any later change to the link, design, or placement
Related tools and guides
- [MeCard QR code generator](/mecard-qr-code-generator)
- [vCard QR code generator](/vcard-qr-code-generator)
- [QR payload inspector](/qr-payload-inspector)
- [QR offline verifier](/qr-offline-verifier)
- [QR scan log](/qr-scan-log)
- [blog](/blog)
