Testing typography is not a formality; it is the step that separates a design that looks good from a code that actually works. This guide gives you a repeatable test you can run on any proof, with clear pass checks and fixes for the failures you are most likely to see. You do not need specialist equipment: a printed proof at the final size, two different phones, and the real lighting and viewing distance are enough. Run the test every time something changes, and keep a note of what passed so the next batch starts from a proven setup.
What you need for a typography test
You need a proof printed at the final size on the real material, two different phones with different cameras, and access to the real placement with its real lighting. Bring a ruler or a simple module guide if you want to check the quiet zone precisely, and bring a pen to mark the proof with what you find. Stand at the real distance and read every word aloud without leaning in. Type the printed address into a phone and check it lands on the right page. If either step fails, fix the type.
Step-by-step test
First, look at the proof without scanning. Check the code background is even, the quiet zone is clear on all four sides, and nothing touches the symbol. Second, stand at the real scanning distance and scan with the first phone, noting how quickly it locks on. Third, repeat with the second phone, then repeat again in the weakest light the code will face, and at a slight angle. Fourth, check the supporting text: read the call to action aloud from the real distance, and type any printed address into a phone to confirm it lands on the right page.
How to judge pass or fail, and what to fix
A pass is a fast, first-try scan on both phones, at the real distance, in the real light, with no leaning, shading, or retrying. A scan that eventually works after several tries is a fail, because real users will give up before the third try. If the code fails, change one thing at a time: widen the margin, strengthen the contrast, simplify the decoration, or enlarge the code. Test again after each change, and keep the version that passes as your reference for the next batch.
Putting this into practice
Run the test above on your next proof before you approve it, and write down the result: phones used, distance, lighting, and whether each scan passed on the first try. File the passing proof with the project so the next batch can be compared against it. A short written record turns a one-off test into a repeatable standard.
Common mistakes to avoid
Even when the main rules are followed, small slips still creep in. The most common ones are letting decoration drift into the quiet zone, choosing colors that look distinct but share a brightness, and approving a design from a screen preview instead of a printed proof. Another frequent slip is changing one part of a working design, such as the link or the paper, without retesting the whole thing. Treat every change as a reason to run a fresh proof, and treat any hesitation in a test scan as a signal to simplify rather than to hope the next phone will cope better.
Quick checklist
- Keep dark modules on a light, even background with strong contrast.
- Leave a clear quiet zone on all four sides of the symbol.
- Keep the finder patterns solid, undisturbed, and easy to find.
- Check the code at the real size, on the real material, in the real light.
- Confirm the call to action names the payoff and the typed alternative works.
- Recheck the code after any change to the link, design, size, or placement.
Related tools and guides
- Try the [QR call to action builder](/qr-call-to-action-builder) to check your choices before you commit to a design.
- Use the [QR frame designer](/qr-frame-designer) to confirm the numbers and guardrails for this element.
- Check the [QR safety checker](/qr-safety-checker) for a practical way to verify the finished code.
- Check the [printed QR tester](/printed-qr-tester) for a practical way to verify the finished code.
- Check the [QR placement guide](/qr-placement-guide) for a practical way to verify the finished code.
- Check the [blog](/blog) for a practical way to verify the finished code.
