QR code testing tool

Everything needed to test a QR scanner properly: valid codes across every version and error-correction level, deliberately corrupted symbols, and degraded images — each one labeled with the outcome a conforming reader should produce.

What testing a scanner actually requires

A single working QR code tests almost nothing. It exercises one version, one error-correction level, one mask and one encoding mode, on a clean image. The interesting behavior lives at the edges: the largest symbol your reader handles, the smallest module size it resolves, the amount of damage it recovers, and what it does when recovery is impossible.

Each of those needs a fixture whose expected outcome is known in advance. A code that fails to read is only useful if you know whether it should have read, which is why every case here carries a verdict from a real decoder rather than being handed over as an image and a shrug.

The three kinds of fixture

Reading a manifest

Every download carries a CSV and a JSON manifest, and an undamaged control goes in first. The control matters more than it sounds: without it, a run where everything fails is ambiguous between a strict reader and a broken corpus.

Per file the manifest records what was done, how many modules changed, whether the data was recoverable, how many codewords error correction had to repair, and what the symbol decoded to. The repair count is the most useful column and the least commonly available: it says how much of the recovery budget a case consumed, which turns pass and fail into a margin.

Reproducibility, and why it is not optional

Every generator here is seeded. The same content, level and seed produce byte-identical files, so a fixture can be attached to a bug report and regenerated by somebody else on another machine.

A test corpus that differs between runs cannot be used in a regression suite and cannot be argued about, because two people looking at the same failure are not looking at the same bytes. The seed is recorded in the manifest and in the filename of the archive.

Where the labels come from

This site's own QR implementation, written from ISO/IEC 18004 rather than wrapped around a library: the encoder, the four encoding modes, the Reed-Solomon correction and the decoder. That is what makes labeling possible at all — a wrapper cannot tell you how many codewords a repair consumed.

It is one conforming reader, not every reader, and the pages say so wherever a verdict appears. A phone may do better on a degraded image and worse on a damaged finder. Treat a disagreement as information.

Questions

What can I actually test with these?

Whether your reader recovers the damage the standard requires, whether it refuses damage it cannot recover instead of guessing, the smallest module size it resolves, the largest version it handles, and whether it copes with rotation, low contrast and compression.

Do I need to install anything?

No. Everything is generated in your browser and downloaded as a ZIP. Nothing is uploaded and there is no account.

How many fixtures does one run produce?

Around fifty per run: an undamaged control, roughly seventeen corrupted symbols, and around thirty degraded images, each with a manifest entry.

Can I generate a large batch of valid codes too?

Yes, on the bulk generator: up to 500 codes from a sequence, a CSV, a pasted list or generated test data, with a CSV and JSON manifest.

Are the verdicts guaranteed?

They are what a conforming decoder produced, which is the strongest honest claim available. They are not a prediction of what every scanner will do, and the pages state that wherever a verdict is shown.

Open the testing toolkit →

Make a different kind of code

Invalid QR code generator · Damaged QR code generator · Free QR code generator · QR code generator for a URL · Wi-Fi QR code generator · vCard QR code generator · QR code generator · Bulk QR code generator

Open the generator → · All formats