QR Code Error Correction Explained (L, M, Q, H): Which Level Should You Actually Use?
Pick up any QR code generator and you’ll see four options labeled L, M, Q, and H. Most people leave the default and move on — until the printed code comes back from the shop unscannable, or a marketing team drops a logo in the middle and the whole code dies. The error correction level is not a cosmetic setting. It determines how much physical damage a code can survive, and it directly trades off against how much data the code can hold.
This article explains what those levels actually do inside the QR specification (ISO/IEC 18004), how they change capacity with real numbers, and how to choose the right one for your use case.
What error correction actually is
A QR code doesn’t just encode your data — it also encodes redundant information that lets a reader reconstruct damaged or unreadable parts of the code. The mechanism is Reed–Solomon error correction, the same family of algorithms used on CDs, DVDs, Blu-ray discs, and deep-space communication.
When a QR code is generated, the data payload is split into blocks, and for each block the encoder computes a set of error correction codewords. If a reader later finds modules (the black and white squares) that are unreadable — because of a scratch, a coffee stain, bad lighting, or an overlaid logo — it uses those redundant codewords to mathematically rebuild the missing ones.
Reed–Solomon codes have a useful property: to correct t erroneous codewords at unknown positions, you need 2t redundant codewords. (If you know the positions of the damaged codewords — called “erasures” — each redundancy codeword fixes one.) The error correction level simply controls how much of the total codeword budget is spent on redundancy versus payload.
The four levels, by the numbers
The ISO/IEC 18004 specification defines four error correction levels with these approximate recovery capabilities — the share of codewords that can be damaged and still be fully recovered:
| Level | Name | Recovery capability |
|---|---|---|
| L | Low | ~7% of codewords |
| M | Medium | ~15% of codewords |
| Q | Quartile | ~25% of codewords |
| H | High | ~30% of codewords |
Two important nuances that the single percentage hides:
- The percentage applies to codewords, not module area. The popular rule of thumb “level H survives 30% of the code being covered” is approximately true in practice because damage is usually contiguous, but the formal limit is on damaged codewords. Spatially clustered damage (like a logo) is often easier to survive than the same number of errors scattered randomly, because erasures are cheaper to correct than unknown-position errors.
- Higher levels cost capacity. More redundancy means less room for payload at the same version (size). If the data doesn’t fit, the encoder must jump to a larger version — more modules, denser print, harder to scan from a distance.
Capacity: what the levels cost you in practice
QR codes come in 40 sizes called versions. Version 1 is 21×21 modules, and each subsequent version adds 4 modules per side, up to Version 40 at 177×177. The table below shows maximum character capacities from the specification for three representative payload types, across the four levels. (Byte mode covers arbitrary UTF-8-ish binary data and typical URLs; alphanumeric mode covers 0–9 A–Z space $%*+-./:; numeric mode is digits only.)
| Version | Modules | Level | Numeric | Alphanumeric | Byte |
|---|---|---|---|---|---|
| 1 | 21×21 | L | 41 | 25 | 17 |
| 1 | 21×21 | M | 34 | 20 | 14 |
| 1 | 21×21 | Q | 27 | 16 | 11 |
| 1 | 21×21 | H | 17 | 10 | 7 |
| 5 | 37×37 | L | 255 | 154 | 106 |
| 5 | 37×37 | M | 202 | 122 | 84 |
| 5 | 37×37 | Q | 144 | 87 | 60 |
| 5 | 37×37 | H | 106 | 64 | 44 |
| 10 | 57×57 | L | 652 | 395 | 271 |
| 10 | 57×57 | M | 513 | 311 | 213 |
| 10 | 57×57 | Q | 364 | 221 | 151 |
| 10 | 57×57 | H | 288 | 174 | 119 |
| 20 | 97×97 | L | 2061 | 1249 | 858 |
| 20 | 97×97 | M | 1600 | 970 | 666 |
| 20 | 97×97 | Q | 1120 | 679 | 466 |
| 20 | 97×97 | H | 861 | 521 | 358 |
| 40 | 177×177 | L | 7089 | 4296 | 2953 |
| 40 | 177×177 | M | 5596 | 3391 | 2331 |
| 40 | 177×177 | Q | 3993 | 2420 | 1663 |
| 40 | 177×177 | H | 3057 | 1852 | 1273 |
Read Version 1 carefully: going from L to H cuts byte capacity from 17 down to 7 — a 59% reduction. That trade is usually worth it for print, but it’s a real cost. A long URL that fits comfortably in a Version 4 code at level M might force a Version 6 code at level H, and bigger codes mean smaller modules at the same printed size.
Shorter payloads always beat stronger error correction. A short URL in a low-version code at level H will out-scan a long URL in a high-version code at level L almost every time. If you’re encoding a URL, use a short domain or a redirect. This matters more than any other optimization.
Print size and scanning distance: the 10:1 rule
Error correction can’t save a code that’s simply too small to resolve. The widely used field rule is the 10:1 ratio: the scanning distance should be no more than about 10 times the code’s width. Some references give 10:1 as conservative and cite successful scans closer to 15:1 with good cameras and lighting, but 10:1 is the number to design against.
- Business card code, 2 cm wide → reliable up to ~20 cm
- Poster code, 10 cm wide → reliable up to ~1 m
- Billboard code, 1 m wide → reliable up to ~10 m
Two related constraints:
- Module size. Each module should be at least roughly 0.4 mm (about 2 mils is far too small; 0.4 mm is a common print floor) so phone cameras can resolve it. For a Version 10 code (57 modules), that’s a minimum physical size of about 2.3 cm just for the data area.
- The quiet zone. The specification requires a margin of at least 4 modules of white space around the code. Cropping the quiet zone is one of the most common reasons printed codes fail, and no error correction level fixes it — readers use the quiet zone to find the code’s edges.
Why logos demand level H
Embedding a logo in the center of a QR code is the classic reason level H exists. The logo physically covers modules, destroying the codewords underneath. Level H’s ~30% recovery budget is what makes this survivable.
Practical rules for logo overlay:
- Use H. Always. At M (~15%) a modestly sized logo already eats most of the budget.
- Keep the logo under ~30% of the total code area — and preferably well under, because the covered area is rarely cleanly distributed across codeword blocks. A logo covering 20% of the area at level H is a comfortable design; 28% is gambling.
- Stay in the center. The three finder patterns (the big squares in the corners) and the timing/alignment patterns carry structural data that error correction does not protect in the same way. Center placement avoids them.
- Test on real phones, at real distance, in bad lighting. Not just your flagship phone on a desk. Older Android devices with mediocre cameras are the floor you’re designing for.
Note that generators that let you drop a logo on a code without asking for a level are implicitly betting on the level you chose elsewhere. If you set L and add a logo, you’ve created a code that fails often but not always — the worst possible outcome, because it passes casual testing and fails in the field.
How to actually choose
Level L (~7%) — Digital-only contexts where the image is rendered perfectly: app-to-app handoff, screens, generated tickets displayed on a phone. Clean pixels mean almost nothing can go wrong, so spend the budget on capacity and small size. Rarely the right choice otherwise.
Level M (~15%) — The general default for clean print: business cards, product packaging, documents. Survives normal handling wear, minor print defects, and glare. Most generator defaults land here, and for good reason.
Level Q (~25%) — Harsh physical environments without logo overlay: industrial labels, warehouse shelving, equipment tags, outdoor signage exposed to weather. If the surface will be scratched, dirty, or partially obscured in normal use, Q is the workhorse.
Level H (~30%) — Logo overlay, very harsh environments, or situations where a failed scan is expensive (payment codes, safety-critical labels). Also the right choice when you must print very small and expect low-quality cameras.
The decision tree compresses to: digital → L or M; clean print → M; rough environment → Q; logo or critical reliability → H. And regardless of level: keep the payload short, keep the quiet zone, and respect the 10:1 distance rule.
Verify it yourself
Theory is fine, but QR error correction is easy to test empirically. Generate the same URL at each level with our QR Code Generator and compare:
- Generate the code at level L, then M, Q, and H. Notice the module density increase — that visual density is the redundancy.
- Print the H-level version, cover the center with a coin or sticker (~20% of the area), and scan it. It should still work.
- Try the same with the L-level version. It won’t.
- Take the H-level code and progressively cover more area until scans fail — you’ll find the practical limit is close to the theoretical ~30%.
You’ll also see the capacity trade directly: paste a long URL and watch which version (size) each level requires. That experiment teaches the trade-off faster than any table.
Summary
- Error correction in QR codes is Reed–Solomon redundancy; the level sets how much of the codeword budget is redundancy: L ≈ 7%, M ≈ 15%, Q ≈ 25%, H ≈ 30% recovery.
- Higher levels cut capacity — at Version 1, H holds less than half the bytes L holds.
- Shorter payloads beat stronger correction; shorten URLs before raising levels.
- Design print size with the 10:1 distance rule and never crop the 4-module quiet zone.
- Logo overlay ⇒ level H, logo under ~30% of area, centered, tested on cheap phones.
Generate a few variants with the QR Code Generator and the right level for your use case will be obvious within five minutes.