What you are seeing
This fix makes the code work on both platforms by removing the platform-specific assumption that iPhone happened to forgive. You will decode the payload, rebuild it in the most standard format, and verify it on at least two Android devices with different camera apps. Keep the iPhone passing at every step: a fix that trades one platform for the other is not a fix.
Likely causes
1.
Non-standard payload format — Quick test: decode the payload and compare its field layout with the standard format for that type.
2.
Android camera app lacks built-in scanning — Quick test: try a dedicated scanner app on the same Android phone.
3.
Payload action handled differently on Android — Quick test: check whether Android shows the preview banner but fails on the action that follows.
4.
Encoding problem with special characters — Quick test: decode the payload on both platforms and compare the text exactly.
5.
Camera focus or lens behaviour on that Android model — Quick test: try the same Android phone on other codes and at a different distance.
Step-by-step fix
Step 1: On the failing Android phone, open a dedicated scanner app and try the code. Record whether the built-in camera, the scanner app, or neither can read it.
Step 2: Decode the payload and inspect every field. Rebuild it with the matching generator instead of hand-typing the format.
Step 3: Remove or simplify special characters, and confirm the character encoding is standard.
Step 4: Print a fresh proof from the rebuilt payload and test it on two Android phones with different camera apps.
Step 5: Walk through the full action on Android, not just the scan: does the WiFi join, the contact save, or the page open?
Step 6: Add a short typed fallback beside the code for the action it performs, so Android users have another path.
Step 7: Retest the final proof on iPhone and on both Android phones, and keep the version that passes everywhere.
Putting this into practice
In practice, keep one Android test device in your kit that represents your audience, and test every new payload type on it before launch. A code that only ever meets an iPhone during testing will keep surprising you in the field. Record the before-and-after behaviour with the job file, so the fix is provable rather than anecdotal. When the same failure appears again, that record tells you whether the old fix held or a new cause appeared.
Common mistakes to avoid
- Testing on a single Android phone and concluding that all Android phones behave the same way.
- 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 on iPhone but not Android will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that scans on iPhone but not Android.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The payload uses the standard format for its type
- The code scans on two different Android phones
- The action after the scan works on Android, not just the preview
- 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
- [QR payload inspector](/qr-payload-inspector)
- [QR offline verifier](/qr-offline-verifier)
- [QR scanner](/qr-scanner)
- [QR size calculator](/qr-size-calculator)
- [QR safety checker](/qr-safety-checker)
- [blog](/blog)
