QR Error Correction Explained: Levels, Capacity, Logo Budget

Every QR code you have ever scanned was damaged. Not badly, usually. A little glare, a slightly misprinted module, a thumbprint, a crease. The reason the scan still worked is error correction: redundancy woven into the pattern so the reader can reconstruct data it cannot see clearly. This post explains how that redundancy works, what the four levels L, M, Q, and H actually buy you, and how to budget for the most common deliberate damage of all, a logo in the centre.

Disclosure: I built ToolkitLoop's free QR Code Generator, which runs entirely in the browser and offers all four error correction levels. The codes it creates are static, carry no watermark, and have no redirect layer. Nothing in this post requires that tool, but the examples use its behaviour, including its print guidance of roughly 25 mm or larger, because that guidance is a good anchor for the trade-offs below.

The core idea: redundancy as insurance

A QR code encodes data as modules, the little black and white squares, arranged in a grid. Error correction adds extra codewords computed from the data codewords, using Reed-Solomon error correction over a Galois field. The reader does not need to understand the algebra to use the result. The practical effect is simple: a fraction of the pattern can be unreadable, and the reader can still recover the original data exactly, not approximately. It either reconstructs the data or it does not. There is no degraded mode where a URL comes out almost right.

That all-or-nothing property shapes every decision in this post. A code with too little error correction for its conditions does not scan slowly. It fails. A code with more error correction than it needs does not scan better. It just costs density, because the same content plus more redundancy needs a larger grid, which means smaller modules at any fixed print size, which means a harder scan from any fixed distance. Error correction is insurance, and like all insurance, the question is how much damage you realistically expect.

What L, M, Q, and H actually mean

The four levels are defined by the approximate share of codewords that can be restored: L restores about 7 percent, M about 15 percent, Q about 25 percent, and H about 30 percent. Those percentages describe codewords, not physical area, and they assume the damage is spread in the way the error correction model handles best. A single scratch across one row behaves differently from the same number of damaged modules scattered evenly, and a damaged finder pattern in a corner behaves differently again, because the reader must first locate the code before it can decode anything.

The level also changes the code's capacity at a given version. QR versions run from version 1, a 21 by 21 grid, up to version 40, a 177 by 177 grid. At the same version, raising the error correction level leaves less room for data, so the encoder may need to jump to a larger version to hold the same content. That is why two codes encoding the same URL can look visibly different: one at level L is a sparse grid, one at level H is a dense one. Density is the price of resilience, and it is paid in module size.

So which level should you pick? Start from the conditions, not from habit. Level L suits clean, controlled conditions: a code on a screen, or printed large on flat paper and scanned indoors. Level M is a solid default for ordinary print. Levels Q and H earn their density when the code will face real abuse: outdoor posters, curved packaging, labels that get scuffed, or any code carrying a centre logo. If you do not know the conditions, M is the defensible default, and H is the choice when failure is expensive and space allows a larger code.

The logo budget, worked through

A centre logo is deliberate damage, and it should be budgeted like any other expense. Suppose a logo covers roughly 15 percent of the code's modules. Level M, at about 15 percent restoration, is already fully spent by the logo alone, leaving nothing for glare, print spread, or a crease. Level Q, at about 25 percent, leaves a margin. Level H, at about 30 percent, leaves more. This is why the common advice to pair logos with level H exists, and why it is good advice rather than folklore.

But the budget has subtleties that the percentages hide. First, the logo must not cover the finder patterns, the three large squares in the corners, or the timing patterns that run between them. Damage there is not ordinary data damage, because it interferes with locating and orienting the code. Keep the logo in the centre, well clear of the corners. Second, the logo's own contrast matters: a logo with light and dark regions of its own can confuse a reader that is trying to separate modules from decoration. A simple, high-contrast mark reads as a single obstruction, which is what the error correction model handles best. Third, the logo's size in the generator is capped for a reason, and the cap exists because beyond a certain size no error correction level can save the code. The tool accepts logo files up to 2 MB in PNG, JPG, or WebP, and the file stays on the user's device, but the displayed size limit is the real constraint, and it is there to protect the scan, not to annoy the designer.

A quick decision procedure falls out of this. Pick the highest error correction level the space allows. Place the logo centrally and keep it modest. Generate the code, then decode it with at least two phones, including an older one, from the distance the audience will actually scan from. If it hesitates, shrink the logo or shorten the destination before you lower the error correction level. Lowering the level to make room for a bigger logo is borrowing from the insurance to pay for the damage, and it is the one trade in this post that reliably ends badly.

Capacity, versions, and why short content scans better

The same budgeting logic explains why short content is a performance feature, not just an aesthetic preference. A short URL at level M might fit in a version 3 grid, while the same destination with tracking parameters at level H might need version 7 or higher. At a fixed print size of, say, 30 mm, the version 3 code has far larger modules than the version 7 code, and larger modules survive glare, print spread, and distance better. Every character you add to the destination is paid for twice: once in density, and again in the error correction needed to protect that density.

This also gives a practical way to think about the quiet zone. The quiet zone, a blank margin at least four modules wide on all four sides, is not padding. It is how the reader separates the code from its surroundings. Trimming it to fit a layout is equivalent to spending error correction budget on something that bought you nothing. If a layout cannot afford the quiet zone, it cannot afford the code at that size, and the honest fix is a larger placement or a shorter destination.

Putting it together

A good QR code is a budget, and the budget has four lines: content length, error correction level, logo size, and print size. Spend content length carefully, because it drives density. Spend error correction generously when the code will be printed, handled, or logoed. Spend logo size modestly, and never over the finder patterns. Spend print size according to scanning distance, starting from the roughly 25 mm floor that print guidance suggests and going up for posters and signage. Then verify the whole budget with a real test: one printed copy, at the real size, on the real paper, scanned from the real distance.

You can try this with the free generator at https://toolkitloop.com/qr-code-generator. It generates the code locally in your browser, shows content validity, a digital decode check, and print guidance before you download, and offers PNG or SVG output, with SVG the right choice for print because it scales without softening module edges. If you want to check codes other people made, the companion scanner at https://toolkitloop.com/qr-code-scanner decodes from screenshots and camera input in the same browser-local way.

The elegant thing about QR error correction is that it is invisible when it works. Nobody scans a code and thinks about Reed-Solomon. They think about whether the menu opened. Getting the budget right is what keeps it that way.

Disclosure: I built ToolkitLoop's QR Code Generator. It is free, runs entirely in your browser, and the codes it creates carry no watermark and no redirect layer. What do you budget for first when a code has to survive the real world, the logo or the distance? I am curious where other developers draw that line.