Test methodology
QR code scan testing: a reproducible test method
A reproducible QR scan protocol for devices, distances, lighting, surfaces, logos, and success rates without invented benchmark results.
Short answer
One successful scan is not a reliable release test. Scan the same final code repeatedly with at least one iPhone and one Android device, from the intended distance, under different lighting, and on the real material. Record recognition time, failed attempts, and the correctly decoded destination.
What a reliable test must cover
- Test the final file and material, not a screen preview.
- Record device, operating system, camera app, and test date.
- Vary distance, angle, light, and reflections in a controlled way.
- Run at least three repetitions per condition.
- Pass only when the entire payload is decoded correctly.
The test matrix
Apple and Google both instruct users to keep the complete code in the camera view. Google also names steady handling, good light, and avoiding glare as troubleshooting steps. These conditions therefore belong in a reproducible protocol.
| Dimension | Record at minimum |
|---|---|
| QR code | Payload, version/module count, error correction, size, colors, logo |
| Output | SVG/PNG, printer, paper or surface, matte/glossy |
| Device | Model, operating system, camera app |
| Situation | Distance, angle, lighting, movement |
| Result | Recognition time, attempts, decoded payload, failure mode |
Standard procedure for each test case
- Clean the camera lens and enable automatic QR recognition.
- Start front-on at the defined distance without digital zoom.
- Start timing while aligning; log a failed attempt if recognition takes longer than three seconds.
- Run three repetitions and move the camera away between attempts.
- Then change angle, light, or distance one variable at a time.
- Compare the displayed link or content character by character with the expected payload.
Fair-QR recommended release criterion: 3 of 3 correct scans within three seconds each in the intended use condition.
Variants that should be tested separately
- Standard design versus logo or gradient design.
- Short target URL versus the longest intended payload.
- Original size versus the smallest size used in the layout.
- Matte proof versus glossy, curved, or behind-glass placement.
- Good indoor light versus the realistic worst location.
- Offline QR versus Smart QR to verify the final destination and redirect, not the visual symbol alone.
Publish results so they remain verifiable
A published benchmark should include setup, devices, operating-system versions, QR files, and every failed attempt. An average alone can hide problematic edge cases. Useful metrics include success rate, median recognition time, and the most difficult condition that still passed.
Fair-QR will not infer a claim such as “works on every smartphone” from this protocol. A test only supports the devices, apps, and conditions actually tested.
Primary sources and basis
Device guidance comes from platform vendors; the release criterion is a disclosed Fair-QR method.
Related resources
Print guide
How to print QR codes: size, contrast, and quiet zone
A technical QR code print guide covering the quiet zone, module size, error correction, logo rules, and a verifiable preflight checklist.
Open technical resourceArchitecture and privacy
QR code privacy: Offline QR and Smart QR explained
A technical Fair-QR architecture overview: what stays local in Offline QR, which normal website data exists, and how Smart QR is processed separately.
Open technical resourcePrepare your own test code
Create a final SVG and change only one variable at a time during the test series.