What the QR code validator checks before you print
The QR code validator is a pre-print QA step: it renders your code, decodes it, then re-decodes it after each of 14 simulated real-world conditions and returns a Print-ready, Needs attention, or High risk verdict with a one-page PDF report. Run it on the final link or artwork before a job goes to press.
Nothing leaves your browser. Rendering, decoding, the stress simulation, and the PDF are all done on your device; no link, image, or result is uploaded.
The 14 conditions
Each condition is applied at two to four rising severities, and the code is decoded again after every one. They fall into three groups, plus a combined test.
| Group | Conditions |
|---|---|
| Camera & Optics | Out-of-focus blur, motion blur (camera shake), low light, glare, screen moiré (photographing a code off another screen) |
| Print & Reproduction | Low contrast, downscaling to 500 / 250 / 150 / 100 px, JPEG compression, print noise and uneven inking, surface curvature (a bottle or cup) |
| Placement & Design | Rotation and perspective tilt, a central logo or sticker, corner (finder-pattern) damage to one or two corners |
| Combined Scenarios | A "real-world combo" that stacks mild blur, reduced contrast, a slight tilt, and compression, in good / typical / poor versions |
The combined test is the one to watch, because real scans often go wrong through several small problems at once: a code printed slightly too small, a slightly dirty lens, and light that is a little too dim.
How the verdict is decided
Every condition earns a badge: Pass (decoded at all severities), Weak (decoded at the mild levels, failed a harder one), or Fail (failed at the mildest level). The validator also grades the quiet zone, the blank margin, as Adequate (4 or more modules), Tight (2 to 4), or Missing (under 2). The overall verdict follows fixed rules:
| Verdict | Set when |
|---|---|
| High risk | The code can't be decoded at all, or the quiet zone is Missing, or the combined test fails twice, or four or more conditions Fail, or the simulation score is under 45% |
| Needs attention | The quiet zone is Tight, or at least one condition Fails, or four or more are Weak, or the simulation score is under 68% |
| Print-ready | None of the above: the code decoded cleanly and held up across the suite |
One practical consequence: a couple of Weak badges on an otherwise-clean, comfortably-sized code still reads as Print-ready. The verdict reacts to patterns of weakness, not a single soft spot.
What the simulation score means
The percentage under the verdict is the share of individual decode attempts that succeeded: the baseline decode, 42 stressed decodes, and the quiet-zone check, 44 in total. It's a quick summary, not a prediction of how any one phone or printer will behave. The per-condition badges and the fixes list are the real output.
Example: when raising error correction makes a code worse
A common instinct is to set error correction to H "to be safe". Consider this hypothetical walkthrough; its values illustrate how to read a report, not a measured benchmark. You paste a long campaign URL, roughly 180 characters once every tracking tag is on it, into the Check by content tab and choose H, 30% recovery (best for logos / rough surfaces), then press Validate.
https://riverside-cafe.example/autumn-menu-launch?utm_source=table-tent&utm_medium=qr&utm_campaign=fall-menu-2026&utm_content=window-seats&utm_term=oat-milk-latte
Inspect Code details and record the actual module count, then read the per-condition results. Level H adds error-correction codewords; the approximate 30% restoration figure does not mean that 30% of the image can be covered arbitrarily.
For comparison, try a shorter URL you control and run the same settings again. Record whether the version and stressed decode results change. A shorter payload may improve module size at a fixed print width, but it introduces a maintained redirect if you use one. Do not assume every condition will pass.
Test the error-correction level and logo that will actually be printed. Export the report as evidence of the software checks, then test a physical proof on the intended surface and scanners. The report is not print certification.
Reading the code details panel
| Field | What it tells you |
|---|---|
| Encoded content | The text the code actually decoded to. Check it matches what you intended, character for character. |
| Error correction | The level you chose on the content tab. Uploaded images show a placeholder dash because the level can't be read back from a finished code. |
| Matrix / Version | The grid size. More encoded data means a higher version and a denser grid, so each module is smaller at the same print size; the root cause of most blur and downscaling failures. |
| Quiet zone | Adequate, Tight, or Missing. Only meaningful for uploaded images; codes rendered from a pasted link are given a wide margin automatically. |
If the verdict isn't Print-ready, the fastest levers are almost always the same two: make the code physically bigger or encode less, and raise contrast and the error-correction level to match the surface. A shorter destination through a redirect does both at once; it shrinks the matrix and frees up room. How QR error-correction levels work covers the L/M/Q/H trade-off in detail.
Who uses this
- Designers handing off artwork: validate the final link before sending files to a client or printer, and attach the PDF so nobody has to re-argue whether the code "looks fine".
- Restaurants and cafés: menu and Wi-Fi codes get printed small on table tents and window decals; exactly the size where a long URL stops scanning.
- Product and packaging teams: paste a whole catalog of product-page links into the Batch tab (up to 100 at once) and get one table showing which items are safe to print.
- Events: check a sheet of ticket or badge codes in a single batch run before the print deadline.
- Anyone reprinting an existing code: use the Check an image tab to test a code you no longer have the source file for.
Validator vs. scannability tester
Both run on the same simulation engine, for different jobs.
| QR Code Validator | QR Scannability & Stress Tester | |
|---|---|---|
| Built for | A fast go / no-go verdict and a shareable PDF | Exploring one code in depth |
| Batch mode | Yes, up to 100 links | No |
| Adjust each condition's severity | No: fixed levels | Yes |
| See the stressed image | No | Yes, side by side |
| Output | Verdict, PDF report, CSV (batch) | Interactive per-condition results |
Use the validator to decide whether to print. Switch to the Scannability Tester when a code is borderline and you want to see exactly where it breaks. To check foreground and background colors on their own, use the Contrast Checker.
Tips, limits, and common mistakes
- It's a simulation, not a guarantee. The stress conditions approximate blur, glare, compression and the rest; a useful early warning, not a substitute for scanning a physical proof.
- Test at the size and level you'll actually print. A code that's Print-ready at error correction M might still need H once a logo goes in the middle. Set the dropdown to match your real plan.
- Upload the production file, not the design mockup. On the Check an image tab, test the exact PNG or SVG that goes to print. A screenshot or a re-exported JPEG has already lost detail the check can't recover.
- The quiet-zone reading only applies to uploads. Codes generated from a pasted link get a wide margin automatically, so that row will nearly always say Adequate; it is describing the test image, not your artwork.
- Batch mode runs a lighter check. To keep 100 codes fast, each one is tested against five representative conditions rather than the full 14. Anything the batch flags, or anything borderline, deserves a full single-code run.
- One stray failure isn't a crisis. The decoder isn't perfect. A single Weak among otherwise-clean results, on a code that is a comfortable size, is usually noise; a pattern of failures is not.
Still print one proof
A Print-ready verdict is a green light to proceed, not a reason to skip the physical proof. Print one copy at final size on the real stock and scan it with two different phones before committing to the full run.