QR Error-Correction Levels: L, M, Q and H

The ISO standard defines four error-correction levels, each able to restore a different share of a damaged code. L (Low) recovers about 7% of the data, M (Medium) about 15%, Q (Quartile) about 25%, and H (High) about 30%. In plain terms, an H code can lose almost a third of its surface and still be decoded, while an L code can only tolerate minor damage.

This works because of Reed–Solomon coding, the same mathematics that protects CDs and satellite transmissions. The redundant bytes let a decoder reconstruct missing modules rather than simply detect that they are gone.

The percentages describe the share of codewords — eight-bit blocks — that can be restored, not the share of the picture. The distinction has a practical edge: a decoder spends two error-correction codewords repairing a codeword whose position it does not know, and only one when it already knows that codeword is missing. So a code with a known obstruction over it, such as a centre logo, survives roughly twice as much damage as one speckled with random misreads from a blurry camera.

Redundancy is not free. The more error-correction data you add, the fewer characters fit in a code of a given size — or the larger and denser the code must grow to hold the same content. Going from L to H can roughly halve the usable capacity. That is why L makes sense for a long URL shown cleanly on a screen, while H suits a short code that must survive the real world.

The numbers are easiest to see in the smallest code. A version 1 QR code always holds 26 codewords in total. At level L, 19 of them are your data and 7 are error correction; at M it is 16 and 10; at Q, 13 and 13; at H, only 9 data codewords against 17 of redundancy. The proportion holds as codes grow: a version 10 code stores 271 bytes at L but 119 at H, and even the largest version 40 code falls from 2,953 bytes to 1,273.

Reed–Solomon operates on codewords in a finite field of 256 values, which lines up neatly with bytes. But the encoder does not simply append a block of parity at the end. From version 3 upward the data is split into several blocks, each given its own error-correction codewords, and the blocks are interleaved before being drawn onto the grid — byte one of block one, byte one of block two, and so on around again.

The reason is burst damage. A coffee ring, a fold or a staple wipes out a contiguous patch of modules. If all of that fell inside one block it would exceed that block's repair budget and the code would be lost. Interleaving spreads the patch thinly across every block, so each loses only a few codewords and each can fix its own share. It is the same trick a CD uses against scratches, and it is why QR codes tolerate real-world abuse rather better than the raw percentages suggest.

There is a counter-intuitive catch. Raising the error-correction level often pushes the code to a higher version, and if the printed size stays the same, every module gets smaller. A 2 cm square holding a version 4 code has modules about 0.6 mm across; the same 2 cm holding a version 8 code has modules under 0.4 mm. Past a certain point the extra redundancy you bought is cancelled out by modules the camera can no longer resolve cleanly, and the code gets harder to scan rather than easier.

So the working rule is: raise the level when the code is free to grow with it, or when the content is short enough that the higher level costs no extra version. If you are pinned to a small label and a long URL, shortening the URL buys more reliability than stepping from M to Q.

Use M as your default — it balances durability and size for most on-screen and printed uses. Step up to Q or H when the code will be printed small, placed outdoors, applied to a curved surface, or exposed to wear. Always choose H when you drop a logo into the centre: the covered modules count as damage, and only the highest level reliably compensates for them.

Even at H, keep a centre logo under about a quarter of the code's width and centred, where the data is least concentrated. Covering a finder pattern in a corner is fatal at any level, because the decoder needs all three to locate and orient the grid before error correction ever runs.

In QRForge the level is a dropdown next to the size slider. Try encoding the same text at L and at H and watch the pattern grow denser — a concrete feel for the trade-off you are making.

Whatever you settle on, test the artefact and not the screen. Print at final size on the final material, then try it from the distance a real person will stand at, in the light they will have, on an older phone as well as a new one. Crumple a spare copy, cover a corner with your thumb, and check that it still reads — that is the margin you are actually shipping.