QR Code Error Correction Levels Explained (L, M, Q, H)

QR code error correction levels — L, M, Q, and H — determine how much damaged, dirty, or obscured data a QR code can recover from, at roughly 7%, 15%, 25%, and 30% respectively. Higher levels trade data capacity for durability, which is the entire decision this guide walks through.

Every QR code generator asks you to pick one of these four letters, usually buried in an "advanced settings" menu, and most people either leave it on the default or guess based on a vague sense that "higher is safer." That guess is usually right directionally and wrong in the details — the real decision depends on exactly how much data you're encoding, whether you're adding a logo, and what environment the printed code will live in. This guide gives you the actual numbers behind that decision: precise recovery percentages, the official ISO/IEC 18004 data capacity table across versions and levels, exactly how large a logo each level tolerates, and a use-case matrix covering everything from business cards to industrial nameplates.

What Are QR Code Error Correction Levels (L, M, Q, H)?

A QR code doesn't just encode your data once — it also encodes redundant recovery data alongside it, using a mathematical technique called Reed-Solomon error correction. In plain terms: the code contains extra "backup" information about its own contents, distributed across the grid, so that if a scanner can't read part of the pattern — because it's dirty, torn, faded, low-contrast, or intentionally covered by a logo — it can reconstruct the missing pieces from what's left, the same way a damaged hard drive with RAID redundancy can rebuild lost data from parity information on other disks.

The four error correction levels set how much of the code's total capacity is spent on this recovery data versus your actual payload

Quick summary for anyone skimming: L recovers about 7% of damaged data, M about 15%, Q about 25%, and H about 30%. Each step up buys real durability, but it isn't free — every percentage point of recovery capacity is a percentage point of your grid that can't hold your actual URL, contact card, or Wi-Fi credentials. That trade-off is the subject of the next section, with the exact numbers most guides on this topic never publish.

How Reed-Solomon Recovery Actually Works, in Plain Terms

A QR code's data isn't stored as one continuous stream — it's broken into small chunks called codewords, each representing 8 bits. Alongside the codewords that hold your actual data, the encoder generates additional error correction codewords using Reed-Solomon coding, a mathematical technique that treats the data as coefficients of a polynomial and computes extra values that let a decoder solve for missing or corrupted terms, provided not too many are missing at once. The practical result: if a scanner reads a QR code and finds that some codewords are unreadable — because that region of the code is torn, smudged, faded, or covered by a logo — it can mathematically reconstruct those missing codewords from the surviving redundancy data, exactly the way a RAID array rebuilds a failed disk's contents from parity data stored across the other disks, or the way a scratched CD still plays audio through the same class of error-correcting code (Reed-Solomon coding was originally developed for, and is still used in, CD and DVD players).

This is also why error correction has a hard ceiling rather than being infinitely scalable: at H level's ~30% recovery capacity, the code can reconstruct itself if up to roughly 30% of its codewords are unreadable, but beyond that threshold, there simply isn't enough surviving redundancy data to solve for what's missing, and the scan fails outright rather than partially. Damage below the threshold is fully recoverable; damage above it is not partially readable — it's a binary pass/fail once you cross the level's recovery ceiling. For a broader look at how the rest of a QR code's structure — position markers, alignment patterns, format information — works together with error correction to make a scan succeed, see this site's guide to how QR codes work.

Why Four Levels Instead of One Fixed Setting?

It's worth being explicit about why the standard defines four discrete tiers rather than either a single fixed setting or a continuously adjustable percentage. QR codes are printed and scanned across an enormous range of conditions — a code on a phone screen faces essentially zero physical risk, while a code laser-etched onto an outdoor industrial part faces UV exposure, abrasion, and years of weather. A single fixed error correction level would either waste capacity on codes that never needed protection, or leave codes in harsh environments under-protected. Four discrete levels — rather than a continuous dial — keep the encoding math standardized and interoperable across every scanner and generator that implements the ISO/IEC 18004 specification, while still giving generators enough range to match the code to its environment. It's a deliberate trade-off between flexibility and universal compatibility, and it's part of why every QR generator, from the simplest free tool to enterprise platforms, implements the same four letters rather than four different competing systems.

How QR Code Error Correction Affects Data Capacity

Here's the mechanic that most explanations of error correction skip entirely: for a fixed QR code size (version), raising the error correction level doesn't just add "more safety" for free — it directly reduces how much data you can encode, because the recovery codewords and the data codewords are competing for the same finite grid of modules. The table below reproduces the official ISO/IEC 18004 data capacity specification for a representative spread of versions, across all three common encoding modes and all four error correction levels.

QR Code Data Capacity by Version, Error Correction Level, and Encoding Mode

A few things worth pulling out of this table directly, since they answer questions people actually search for. At the maximum QR version (40), the absolute ceiling for any QR code — regardless of error correction — is 7,089 numeric digits, 4,296 alphanumeric characters, or 2,953 bytes at the lowest error correction level (L). At the highest error correction level (H) and the same maximum version, that ceiling drops to 3,057 numeric digits, 1,852 alphanumeric characters, or 1,273 bytes — roughly a 57% reduction in usable capacity for the same physical grid size. That's the real cost of choosing H over L: not a vague "less room," but a concrete, ISO-defined percentage.

For most QR codes generated for marketing, contact sharing, or Wi-Fi access — which typically encode a URL, vCard, or short text string well under a few hundred characters — this trade-off rarely matters in practice, because even the smallest usable QR versions comfortably fit that much data at any error correction level. It becomes a real constraint only when you're encoding long data (a full vCard with multiple fields, a long tracking URL with UTM parameters, or embedded Wi-Fi credentials with a long password) and want high error correction for a logo or harsh environment at the same time — a combination covered with real examples in the next section. For the physical print-size consequences of moving up a version, see this site's minimum QR code size guide, which covers the millimeter-level impact of exactly this version bump.

How Error Correction Changes QR Code Size (Module Count) — Real Data Examples

The capacity table above is comprehensive but abstract. Here's the same trade-off made concrete, using four data types anyone generating QR codes actually encounters, showing exactly which QR version — and therefore how many modules — each one requires at each error correction level.

Two patterns are worth calling out here, because they directly answer the "how much bigger does H actually make my code" question that most competing articles either skip or answer with only a single anecdotal example. First, for short payloads — a short URL or a Wi-Fi string — the version increase from L to H is small (one to two versions, a few millimeters at typical print sizes). Second, for longer payloads — a tracking URL loaded with UTM parameters, or a full vCard — the version increase from L to H is considerably larger (three to four versions), because there's less spare capacity in the smaller grid sizes to begin with, so redundancy demands push the code into meaningfully bigger versions faster. Practically: if you're deciding between a short link and a long UTM-tagged URL for a QR code that also needs high error correction (for a logo, say), the short link keeps your printed code noticeably smaller — one more reason dynamic QR codes, which encode a short redirect URL rather than the full destination, tend to stay in a lower, more logo-friendly version even at H error correction.

Does Higher Error Correction Slow Down Scanning?

Practically, no — not in any way a user would notice. Modern phone camera decoders process the Reed-Solomon recovery math in a fraction of a second regardless of error correction level; the perceptible delay in scanning a QR code is almost entirely due to camera autofocus and frame capture, not decoding time. Where error correction level can introduce a genuine, if small, difference is in decoding when a scanner actually needs to invoke the recovery math — a clean, undamaged code at any level decodes essentially instantly, but a code that's actually damaged and relying on H-level recovery to reconstruct missing codewords does slightly more computational work than one that's undamaged. On any phone made in the last several years, that difference is not measurable by a human waiting to see the scan resolve. The practical implication: don't avoid higher error correction out of a concern that it will make codes feel slower to scan — that concern isn't borne out by how modern decoders actually perform, and it shouldn't factor into the level decision at all.

Error Correction for Dynamic vs. Static QR Codes

One distinction that's easy to miss: error correction level is a property of the printed pattern itself, not of whether the code is dynamic or static — but the two interact in a way worth understanding before you print. A static QR code encodes your full destination URL directly, so a long destination (say, a product page URL with several tracking parameters) consumes real capacity that competes directly against your chosen error correction level, per the module-count table above. A dynamic QR code instead encodes a short, fixed-length redirect URL — typically 20-30 characters regardless of how long or complex the actual destination page is — and the redirect service resolves that short link to wherever you've currently pointed it.

The practical consequence: a dynamic QR code's physical size and version stay small and predictable even at H error correction with a logo, because the encoded payload never grows past that short redirect length, no matter how the destination changes over time. A static code encoding the same long destination URL at H level, by contrast, can be pushed into a noticeably higher version — and therefore a physically larger printed code — simply because the full URL has to live inside the pattern itself. This is one of the more concrete, measurable reasons dynamic QR codes tend to be the better technical choice whenever you're also embedding a logo or targeting a harsh environment that calls for Q or H: you get the durability benefit without the size penalty that comes from encoding a long URL directly. For the fuller comparison of how the two behave differently after printing — not just at generation — see this site's guide to dynamic vs. static QR codes.

Which Error Correction Level Should You Use for a Logo?

This is the single most common reason people go looking for an error-correction explainer in the first place, and it's also where competing guides tend to get vague. Some explicitly avoid giving a percentage threshold at all; others give a number but bury it in unrelated paragraphs instead of a clear reference table. Here's the integrated version — recovery percentage and safe logo coverage in the same row, so you can look up both at once

Two important caveats on that "safe max coverage" column, stated plainly rather than left implicit the way most sources leave it. First, these percentages are practical, cross-checked industry guidance, not a number written into ISO/IEC 18004 itself — the standard defines the error correction math and recovery capacity, but doesn't specify a logo-coverage percentage, since logo placement isn't part of the core symbol specification. Second, coverage percentage alone isn't the full story: a logo covering 20% of the code's area in the center is far safer than the same 20% spread across an edge, because the three large corner squares (the position detection patterns scanners use to orient the code) and the smaller alignment pattern near the fourth corner must never be touched, regardless of error correction level or overall coverage percentage. A logo that respects those zones can push toward the higher end of the H range; one that doesn't can fail well below it.

Worked example: a business card QR code is generated at Version 3 (29×29 modules, 841 total modules) and printed at 2cm square, encoding a short redirect URL at H error correction. A logo occupying 20% of that area covers roughly 168 of the 841 modules. At H level's ~30% recovery capacity, the code can tolerate losing up to about 252 modules' worth of data (30% of 841) before decoding fails — so a centrally-placed 168-module logo, safely clear of the corner markers, uses up about two-thirds of the available recovery budget, leaving real margin for additional real-world degradation like dust, glare, or a slightly imperfect print. Push that same logo to 30% coverage (roughly 252 modules) and it consumes the entire recovery budget on the logo alone, leaving zero margin for anything else — which is exactly why 25% is treated as a safer practical ceiling than the theoretical 30% maximum: it reserves headroom for the imperfect conditions every printed code eventually faces, rather than assuming the logo is the only source of degradation the code will ever encounter.

The practical rule that follows from this table: if you're embedding any logo at all, use Q or H — never L, and treat M as a minimum floor only for very small, corner-safe logos. Below Q, there simply isn't enough recovery capacity left once a logo occupies real estate, and the failure mode is rarely a clean "doesn't scan at all" — it's intermittent, phone-dependent scanning that looks like a mysterious bug rather than an error-correction shortfall, which makes it a frustrating problem to diagnose after the fact if you don't already know to check this setting first.

Which Error Correction Level Should You Use? (By Use Case

Beyond logos, the environment a printed QR code lives in — how much handling, moisture, dirt, or wear it will realistically face — is the other major factor in choosing a level. The table below covers a wider spread of real placements than the handful of scenarios most competing guides list, with the reasoning included rather than just a bare recommendation.

The pattern across this table: error correction level should track expected physical degradation, not campaign importance. A high-budget marketing campaign printed on clean, indoor flyers doesn't need H just because the campaign matters — it needs whatever level matches how that specific piece of paper will actually be treated. Conversely, a low-cost warehouse label in a dusty environment genuinely benefits from H even though nobody would call it a "marketing asset." Matching the level to the environment, not the perceived importance of the code, is the actual decision rule.

A worked scenario that illustrates this: a coffee brand prints 10,000 bags with a QR code at the default M level, no logo, pointing customers to a brewing guide. Three months in, scan reports come back inconsistent — the code works fine on bags stored indoors but fails intermittently on bags that traveled through a humid shipping container and picked up light surface condensation damage plus minor creasing at the fold seam. The fix isn't a redesign or a different destination — it's recognizing that "food packaging exposed to moisture and handling" belongs in the H-level row of the table above, not the M-level default the generator shipped with. The brand regenerates the code at H, reprints the next batch, and the inconsistent-scan reports stop. Nothing about the artwork, the logo, or the destination URL changed — only the error correction level, matched correctly to the environment the packaging actually experiences rather than the environment it was assumed to experience at the design stage.

Frequently Confused: Error Correction vs. Contrast vs. Quiet Zone

Error correction level gets blamed for scan failures that are actually caused by something else entirely, often because it's the one setting people know exists and can control, while contrast and quiet zone are less visible "invisible" requirements baked into the code's basic layout. It's worth being clear about the boundary: error correction recovers from damage to a code that is otherwise correctly formed — dirt, tears, logo obstruction, fading. It does not compensate for a code that was generated or printed incorrectly in the first place. Two failure modes commonly mistaken for an error-correction problem

• Insufficient contrast between modules and background. A QR code printed in light gray on white, or a color combination with too little brightness difference, can fail to scan even at H error correction, because the scanner can't reliably distinguish which modules are "on" and which are "off" in the first place — there's nothing damaged to recover from; the base read is failing. No error correction level fixes a fundamentally low-contrast design.
• Missing or inadequate quiet zone. ISO/IEC 18004 requires a clear margin of at least four modules on all sides of the code, free of any other content, so the scanner can isolate the code's position markers from surrounding visual noise. A code crammed right up against text, a border, or another graphic element can fail to scan regardless of error correction level, because the scanner never successfully locates the code's boundaries to begin decoding it at all.

The distinction matters practically: if a code is failing to scan at all — not intermittently, but consistently across multiple devices — raising the error correction level is very unlikely to be the fix, because the problem is more likely upstream of where error correction operates. Error correction is the right tool for "sometimes scans, sometimes doesn't, especially when part of the code is obscured or worn" — not for "never scans, on any device, under any condition."

How to Pick Your Error Correction Level: A 4-Question Checklist

If none of the use cases above match your situation exactly, run through these four questions in order — they cover the same logic the table above encodes, generalized to any new scenario

1. Is there a logo, icon, or any visual element covering part of the code? If yes, you need at minimum Q, and H if the logo covers more than about 18-20% of the code's area. If no, move to question 2.
2. Will the printed material be exposed to dirt, moisture, abrasion, or repeated folding? (Think: outdoor signage, apparel, warehouse floors, food packaging.) If yes, use Q or H depending on severity. If it's a clean, indoor, low-handling surface, move to question 3.
3. Is the destination data unusually long (a full vCard, a long UTM-tagged URL, embedded Wi-Fi credentials with a long password)? If yes and you also answered yes to question 1 or 2, be aware the version jump will be larger than typical (see the module-count table above) — consider shortening the payload (a short redirect URL instead of the full destination) before defaulting straight to H. If the data is short, capacity isn't a binding constraint at any level.
4. Is this code going on a screen or otherwise never leaving a controlled digital environment? If yes, L is genuinely sufficient — there's no physical damage risk to protect against, and maximizing data capacity is the more useful trade.

Landing on M by default when none of these clearly point elsewhere is a reasonable fallback — it's the industry-standard middle ground for exactly that reason.

Testing Your Error Correction Choice Before You Print at Scale

Choosing a level from the tables and checklist above gets you a well-reasoned starting point, not a guarantee — the only way to confirm a specific error correction level actually works for your specific logo, paper stock, and print method is to test it. A short, repeatable process

1. Generate the code at your chosen level and export it at the final print size and resolution (see this site's minimum size guide for the DPI and pixel requirements that apply regardless of error correction level).
2. Print one physical copy on the actual material — screen previews don't reveal how ink spread, paper texture, or lamination will affect the printed module edges.
3. Scan the physical copy on at least two different phones (one iOS, one Android) — decoder implementations vary enough between platforms that a code relying heavily on its recovery margin can behave differently across devices.
4. Deliberately test degraded conditions if the code is going somewhere that will see wear: fold a corner, add a light smudge, or scan it at a slight angle, to see whether the chosen level actually holds up the way the tables above predict for your specific combination of logo, material, and print quality.
5. If any of those tests fail, move up one level rather than redesigning the logo or print layout first — it's the cheapest variable to change and the one most likely to be the actual cause of a marginal scan failure.

This test-before-scale step matters more than the specific level you land on. A code chosen at the theoretically "correct" level for its use case can still fail if the printer's actual output quality is lower than assumed, and a code chosen slightly conservatively (one level higher than strictly necessary) rarely causes a real-world problem, since data capacity is abundant relative to typical payload lengths for the vast majority of QR code use cases covered in this guide.

Common Mistakes When Choosing an Error Correction Level

• Leaving every code on the generator's default without checking it. Most tools default to M regardless of what you're encoding; that's a fine baseline but is actively wrong for both ends of the spectrum — too little redundancy for a logo-heavy outdoor code, too much wasted capacity for a clean digital-only code.
• Adding a logo without raising the level to compensate. This is the single most common cause of "scans on some phones, not others" reports — the code often technically still contains enough information to decode in principle, but different phone camera and decoder combinations have different tolerance for how much of the pattern is missing, so failures show up inconsistently rather than uniformly.
• Assuming higher is always safer with no downside. H is not a universally "better" setting — for long data at a fixed print size, jumping straight to H can force a version bump big enough to require a noticeably larger printed code, which itself can cause a different kind of scan failure if the print space is constrained (see the minimum size guide for how version and physical size interact).
• Not retesting after changing the error correction level. Because raising the level can change the QR version and therefore the module grid density, a code that scanned reliably at M can behave differently — usually better, but worth confirming — after being regenerated at Q or H; treat any error-correction change as a reason to re-run your scan test, not just a settings tweak.
• Confusing error correction with encryption or security. Error correction protects against physical damage and obstruction; it has nothing to do with whether the destination link is safe, private, or trustworthy. Higher error correction does not make a QR code more secure in any data-protection sense.
• Treating error correction as a fix for contrast or quiet-zone problems. As covered above, a code that fails to scan consistently on every device usually has a base formation issue — contrast or quiet zone — that no error correction level will resolve. Raising the level in response to that kind of failure wastes time without addressing the actual cause.
• Choosing a level based on file size or generator speed rather than the code's real-world environment. Higher error correction levels do add slightly more processing during generation and marginally larger output files, but on any modern generator this difference is negligible — it's not a legitimate reason to under-provision error correction for a code that's actually going somewhere harsh.

Primary Sources

The percentages, capacity figures, and structural facts in this guide are drawn from the QR code symbol specification itself rather than secondhand summaries: ISO/IEC 18004 (the international standard defining QR code symbol structure, error correction, and data capacity, most recently revised in 2024) and the underlying Reed-Solomon error correction algorithm, originally published by Irving S. Reed and Gustave Solomon in 1960 and adopted into numerous data-storage and transmission standards since, including CD/DVD encoding and QR codes. Logo-coverage percentages and use-case recommendations in this guide are practical, cross-checked industry guidance built on top of that specification rather than clauses within it — each is labeled as such throughout rather than presented as if it were part of the official standard, since the standard itself is silent on logo placement and environmental use-case matching.

How to Set the Right Error Correction Level in OwnQR

Most QR generators, OwnQR included, expose error correction level as a simple L/M/Q/H selector during code creation, typically defaulting to M unless you change it. The practical workflow that follows from everything above: pick your level using the checklist in this guide before uploading a logo, since adding the logo first and then discovering the default level is too low means regenerating the code and reprinting anything already produced from the old version. This is one area where free and paid tools genuinely don't differ — every mainstream generator, including free tiers, exposes all four error correction levels; error correction isn't a premium feature anywhere in this market, and any tool that locks it behind a paywall is worth avoiding for that reason alone.

Where a one-time-purchase tool matters more directly to this decision is the dynamic-code angle covered earlier: since a dynamic QR code encodes a short, fixed-length redirect rather than your full destination URL, it stays in a lower QR version — and therefore a smaller, more logo-friendly printed size — even at H error correction, without needing a recurring subscription to keep that redirect editable. If your printed material is going somewhere that calls for Q or H (a logo, an outdoor sign, packaging), pairing that decision with a dynamic code is a reasonable default; if you're printing a plain static link with no logo on a clean indoor surface, a free static code at L or M is entirely sufficient, and there's no reason to pay for anything more.

The Bottom Line

QR code error correction levels — L (~7% recovery), M (~15%), Q (~25%), and H (~30%) — set how much damaged, dirty, or obscured data a code can recover from, at the direct cost of how much data it can hold. The decision that actually matters in practice comes down to two questions: is there a logo (if so, use Q or H, and keep logo coverage under roughly 20-25% of the code's area while never touching the corner markers), and will the printed material face real physical wear (if so, match the level to the severity — Q for moderate exposure, H for harsh or continuous exposure). For clean, controlled, low-handling uses like digital screens or indoor flyers, L or M is genuinely sufficient and preserves more data capacity for longer URLs or contact details. Whatever level you land on, retest the code after any change — because raising error correction can bump the QR version and change the physical module density, which is a separate variable from the error correction decision itself but one that interacts with it directly.

None of the tables in this guide substitute for the physical test described earlier: generate at the level the checklist points to, print one real copy on the real material, and scan it on two different phones before committing to a full run. Error correction level is one of the few QR code settings with hard, standardized numbers behind it — 7/15/25/30% isn't a marketing estimate, it's defined in the same ISO/IEC 18004 specification every compliant generator implements — which makes it one of the more reliable levers available when a printed code needs to survive conditions rougher than a clean desk scan. Get the level right relative to your logo and your environment, keep the underlying data short where you can, and the physical test at the end will almost always just confirm what the tables already predicted, rather than surface a surprise.

Frequently Asked Questions

What is a QR code error correction level?
It's a built-in redundancy setting — L, M, Q, or H — that determines how much of a QR code's data can be reconstructed if part of the code is dirty, damaged, or covered, using the same underlying math (Reed-Solomon error correction) used in CDs, DVDs, and RAID storage systems. Higher levels recover more damage but leave less room for actual data.

What do L, M, Q, and H mean in QR code error correction?
They're the four standardized error correction levels defined in ISO/IEC 18004, each recovering a specific percentage of damaged data: L recovers about 7%, M about 15%, Q about 25%, and H about 30%. Each step up trades data capacity for durability.

Which error correction level should I use for a QR code with a logo?
Use Q or H. Level L has essentially no safety margin once any part of the code is obstructed, and M is only safe for very small, corner-clear logos. Q and H both provide enough redundancy for typical marketing logo placements, provided the logo stays clear of the three corner squares.

What's the maximum logo size I can safely add at each error correction level?
Roughly 10% of the code's area at M, 18-20% at Q, and 20-26% at H — treat 25% as a safe practical ceiling at H rather than pushing to the theoretical ~30% limit. These are practical cross-checked guidelines, not numbers specified in the ISO/IEC 18004 standard itself.

Does a higher error correction level make the QR code bigger?
Indirectly, yes, for identical data. More redundancy leaves less room in a given QR version for your actual payload, so the generator may need to step up one or more versions — adding module rows and columns — to fit everything. Short data (like a short URL) sees a small size increase; longer data (like a full vCard) can see a considerably larger one.

Can I change the error correction level after I've already generated a QR code?
No. Error correction level is encoded directly into the QR code's module pattern at generation time, along with the data itself — it isn't a setting stored separately that can be toggled afterward. Changing it means generating an entirely new code, which will have a different module pattern and needs to be retested before it replaces anything already printed.