QR Code Capacity: How Much Data Fits, by Symbol Version and Encoding Mode

How Much Data Can a QR Code Hold?

A QR code holds at most 7,089 digits, 4,296 alphanumeric characters, 2,953 bytes or 1,817 kanji characters. Those four figures describe one symbol - version 40, 177 modules on a side, at error correction level L - and they are the ceiling for the format rather than a target anyone should design towards.

The practical range is much narrower than the ceiling suggests. A version 40 symbol printed at the 0.4 mm module floor for coated stock is 71 mm across before its margin, and every module in it has to survive being photographed - so codes that size appear in industrial marking and almost nowhere in signage, packaging or print.

For ordinary use the useful question is the opposite of the maximum: given this payload, what is the smallest symbol that holds it, and what does that symbol cost in printed millimetres. The last two sections of this page answer that directly.

What a Symbol Version Is

The symbol version is the QR standard's name for a code's module count, running from version 1 at 21 × 21 modules up to version 40 at 177 × 177. A version V code is 4V + 17 modules on each side, so the versions step in fours: 21, 25, 29, 33, 37 and so on.

A version is not something you choose. The encoder picks the smallest version that holds the payload at the requested error correction level, which means the version is a result of two decisions you do make - what the code says and how much damage it should survive.

Two consequences follow, and both catch people out. First, capacity moves in steps rather than continuously: adding one character to a payload can be free or can push the code up an entire version. Second, a higher version is not a bigger picture - it is a denser one. At a fixed printed width, a version 10 code's modules are roughly 40% narrower than a version 4 code's - 57 cells across the same space instead of 33 - and small modules are what scan failures are made of.

Not all of a symbol is available for content. In a version 1 code, 233 of the 441 modules are function patterns and format information rather than data - finder patterns and QR code anatomy accounts for where they go. What remains after that is split between your data and its error correction.

The Four QR Encoding Modes

An encoding mode is the scheme a QR code uses to turn characters into bits, and the standard defines four: numeric, alphanumeric, byte and kanji. Each packs characters at a different density, so the same symbol holds a very different number of them depending on which mode the content permits.

Alphanumeric mode is the one worth understanding, because it is the only one that applies to URLs. It is the QR encoding scheme that packs two characters into 11 bits, using a 45-character set of digits, capital letters, space and eight punctuation marks. Lower-case letters are not in that set, and neither are the question mark, the ampersand, the equals sign or the underscore.

The mode is chosen by the encoder, not by the person typing the payload. Some encoders analyse the content and switch modes automatically, some split a payload into segments and use a different mode for each, and many encode everything in byte mode regardless. That last case is common enough that the only reliable way to know is to generate the code and count its modules.

QR Code Capacity by Version and Mode

The table below is the reference the rest of this page is built on: how many characters each symbol version holds, in each mode, at each error correction level. Read it by finding the row for your level and the version whose figure first exceeds your payload.

Two cells in this table are worth reading together. Version 25 at level L holds 1,273 bytes, and version 40 at level H holds exactly the same 1,273 bytes - a symbol with more than twice the module area, spending the whole difference on recovery. Capacity gained by growing the code and capacity lost by raising the level are the same currency, which is why both decisions belong in one table rather than two.

Why the Same URL Fits in a Smaller Code in Capitals

A URL written in capitals can encode in alphanumeric mode at 5.5 bits per character instead of byte mode's 8, which is a 31% saving and frequently drops the symbol by a whole version. HTTPS://EXAMPLE.COM/MENU uses only characters from the 45-character alphanumeric set; https://example.com/menu does not, because lower-case letters are not in it.

The catch is that only part of a URL is safe to capitalise. Schemes and host names are case-insensitive, so HTTPS://EXAMPLE.COM and https://example.com reach the same server. Everything after the host is case-sensitive on most web servers, so capitalising a path can produce a code that scans perfectly and lands on a 404.

What that leaves is a rule with a narrow but real application: capitalise the scheme and domain, keep the path exactly as the server expects it, and check whether the symbol actually shrank. A payload that mixes cases falls back to byte mode entirely, so a single lower-case character in the path removes the whole saving.

Two further limits are worth stating honestly. The alphanumeric set has no question mark, ampersand, equals sign or underscore, so any URL carrying query parameters is in byte mode whatever its case. And the encoder has to support mode switching at all - many generate every payload in byte mode, in which case capitalising changes nothing. Generate the code both ways, count the modules on one side, and compare: if the number is the same, the mode did not change.

Error Correction Is Half the Capacity Question

Raising the error correction level from L to H removes about 57% of a symbol's capacity, because the recovery codewords and the data codewords come out of the same fixed budget. At every version, the four levels divide the same total: level L spends about 7% of it on recovery, M about 15%, Q about 25% and H about 30%.

The interaction that surprises people runs the other way as well. Because capacity moves in steps, raising the level often costs nothing at all: if your payload is 40 bytes, level M and level Q both land you on version 4, and the higher level is free. Generate the code at your chosen level, note the module count, generate it one level higher, and take the higher level whenever the grid is unchanged.

Error correction levels L, M, Q and H covers what the recovery capacity actually buys, how large a logo each level tolerates, and why raising the level after a scan failure usually makes the code worse rather than better.

From URL Length to Printed Size

Payload length decides the symbol version, and the symbol version decides the smallest size the code can honestly be printed at. This is the chain that matters in a layout, and it is why shortening a URL is a print decision rather than a tidiness decision.

The last two rows are the argument for link shortening in one place. A 200-character tracking URL at level H cannot be printed below about 34 mm on coated stock, and a 25-character one can go to 16 mm - the same information, delivered by the same code, at less than a quarter of the area.

These are floors, not recommendations. A code should also be sized for its reading distance, which is roughly 1 cm of width for every 10 cm of scanning distance, and whichever of the two numbers is larger is the one that governs. The minimum size for print takes that calculation end to end, and the QR print size calculator runs it for a given distance.

What to Do When a Payload Does Not Fit

A payload that will not fit at a workable size is almost always a URL problem rather than a QR code problem. The symbol is doing what it was asked; the ask is too long. In rough order of how much they save:

• Remove the tracking parameters. A full UTM set with a click ID routinely adds 80 to 120 characters, which is three or four symbol versions on its own. Attach the campaign data at the destination instead of in the printed code.
• Drop www and the trailing slash. Small, free, and worth about a version on a short URL where every character counts.
• Use a short path. example.com/menu rather than example.com/restaurant/our-menus/lunch-menu-2026. On print, the path is read by a camera, never typed by a person, so its readability buys nothing.
• Point at a redirect you control. A short path on your own domain that forwards to the long URL keeps the code small and keeps the destination changeable, which a static code otherwise cannot be.
• Encode the minimum for the payload type. A Wi-Fi code carries the network name, password and security type and nothing else; a phone code carries digits. Extra fields cost versions - see QR code types for what each payload actually needs.
• Lower the error correction level, if there is no logo. Going from H to M is not a small saving. It nearly doubles the capacity at every version - 44 bytes to 84 at version 5 - and level M is entirely adequate for a clean code on flat, coated stock.
• Split the job. If the content genuinely is long - a menu, a document, a certificate - put it behind a URL rather than inside the code. A QR code that holds 2,000 characters is a code nobody can scan.

One thing not to do: raise the printed size to fit a long payload and stop there. It works, but it hides the cause, and the next version of the artwork will hit the same wall with a slightly longer URL and less space to give it.

Why Capacity Thresholds Are Uneven

Capacity does not rise smoothly with version, and three separate mechanisms are responsible. Knowing them explains the jumps that otherwise look arbitrary in the table above.

The character count indicator widens. The character count indicator is the short header inside a QR code that states how many characters the payload contains, and its width in bits changes with the symbol version. In byte mode it is 8 bits at versions 1 to 9 and 16 bits from version 10 upward, so crossing that boundary costs a byte of overhead before any content is stored.

Error correction blocks divide unevenly. From version 5 the data is split into blocks of differing sizes so the recovery arithmetic stays tractable, and the block structure changes at almost every version. Two adjacent versions can therefore gain 20 bytes and then 38.

Remainder bits are left over. Some versions have 3, 4 or 7 modules left after the codewords are laid out, which are filled with zeroes and carry nothing. They are part of why the module count and the capacity do not track each other exactly.

None of this changes what to do. It does explain why adding one character to a URL sometimes costs nothing and sometimes adds four modules to every side - and why the only trustworthy way to know the version is to generate the code and count, rather than to estimate from the character count.

When Capacity Is Not the Real Limit

Most codes hit a physical limit long before a capacity limit, and mistaking one for the other is the common error on this subject. A version 20 symbol holds 666 bytes at level M, which sounds generous until the code has to be printed: 97 modules per side at the 0.4 mm floor is 42 mm of footprint, and squeezed onto a 30 mm table tent its modules fall to 0.29 mm - below what most print processes hold and below what a phone camera resolves at arm's length.

The limits that bite first, in the order they usually arrive:

• Printed module size. Modules should be 0.4 mm or larger on coated stock and 0.5 mm or larger on uncoated. This is what turns a payload length into a minimum width, and it is not negotiable by the design.
• Reading distance. A code needs roughly 1 cm of width for every 10 cm between it and the camera. A dense code on a wall sign fails at the distance people stand, not at the distance it was designed at.
• Camera focus. Phone cameras have a minimum focus distance of about 10 cm. A very small, very dense code forces the reader closer than the camera can focus, which reads as a code that will not scan.
• Contrast and finish. A dense code has less tolerance for low contrast and for glare, because each module contributes fewer pixels - check a colour pair with the QR contrast checker before committing to it.
• Export resolution. A raster export needs whole pixels per module; a dense code at a small pixel size produces anti-aliased module edges. Resolution and DPI has the arithmetic, and SVG avoids the problem entirely.

KoloQR, a free QR code generator with circular and custom-shaped QR codes, exports both PNG and SVG, so a code whose payload forces a high symbol version can be placed as vector artwork and stay geometrically exact at any printed size. That solves the export half of the problem and none of the other four: a long payload still needs a physically larger code, whatever it is exported as.

Common Mistakes About QR Code Capacity

The most common mistake is treating the 2,953-byte maximum as a working budget. It describes a 177 × 177 module symbol at the lowest error correction level, which is not a code that belongs on a menu, a label or a poster - and a payload anywhere near it will have failed for physical reasons long before capacity becomes the constraint.