At the largest symbol the specification defines, version 40 at the lowest error correction level, one QR code holds 7,089 numeric characters, 4,296 alphanumeric characters, 2,953 bytes or 1,817 kanji. Almost nobody reaches those figures, because the limit you actually meet is physical: every extra character pushes the grid up a version, and more modules in the same printed square means each one gets narrower than a camera can resolve.
Encode the word "hello" and you get a tidy 21x21 grid, sparse enough to redraw on graph paper. Encode a 300-character campaign link and the same tool hands back a dense thicket that needs a two-inch print before any phone will read it. Same standard, same generator, two very different objects.
The capacity question usually gets answered with a table of maximums. Those numbers are real. Almost nobody reaches them.
The published ceilings
At the largest symbol the specification defines, version 40, with error correction set to its lowest level (L), a single QR code holds:
- 7,089 numeric characters
- 4,296 alphanumeric characters
- 2,953 bytes
- 1,817 kanji characters
A version 40 symbol is a 177x177 grid, which is 31,329 individual modules. To print that so a phone camera can resolve each square, you need a code several inches across. And error correction L is the level that tolerates the least damage. So the maximum-capacity code is simultaneously the largest and the most fragile version of itself, which is why the ceiling is a trivia answer rather than a design target.
The number worth knowing is not the maximum. It is how fast your content climbs the version ladder.
Four encoding modes, four densities
The format packs characters differently depending on what they are. If you want the underlying structure first, what a QR code actually is covers the anatomy.
Numeric handles digits 0 through 9 and squeezes three of them into 10 bits. Densest mode by a wide margin, which is why 7,089 is the headline figure.
Alphanumeric covers 45 characters: digits, uppercase A to Z, space, and the punctuation set $ % * + - . / and colon. Two characters ride in 11 bits.
Byte mode spends a full 8 bits per character and takes anything that fits the character set, typically Latin-1 or UTF-8. No packing trick applies.
Kanji mode uses 13 bits per Shift-JIS character, which beats sending the same character as multiple UTF-8 bytes.
Look closely at the alphanumeric set. No lowercase letters. No question mark, no ampersand, no equals sign, no underscore, no tilde.
Why a link almost always lands in byte mode
Take a URL like https://example.com/spring-sale?utm_source=flyer. It has lowercase letters, a question mark, an equals sign and an underscore. None of those exist in alphanumeric mode, so the encoder drops that content into byte mode at 8 bits per character. Every character you add costs a full byte.
This is why tracking parameters are expensive. A clean 40-character link and the same link carrying four UTM values can differ by more than a hundred characters, and the second one can sit several versions higher.
The spec does allow mixing modes inside one symbol, and some encoders uppercase the scheme and host so that portion can travel in alphanumeric mode. Useful, but limited: the path and query are case-sensitive, so they still cost a byte each.
Versions 1 to 40 and the size ladder
Version 1 is 21x21 modules. Each step adds four modules per side, so version 2 is 25x25, version 10 is 57x57, version 20 is 97x97, and version 40 arrives at 177x177.
Your generator picks the smallest version that fits the data at the error correction level you chose. Add a few characters and nothing changes for a while. Add a few more and the grid jumps a step. That jump is where printed codes get harder to read, because at a fixed physical size, more modules means each module is narrower.
Error correction spends the same grid
Redundancy is not free storage bolted onto the side. It lives in the same modules your data does. The four levels recover roughly 7 percent (L), 15 percent (M), 25 percent (Q) and 30 percent (H) of the codewords. Raise the level and you either fit less content at the same version or get bumped to a larger one.
In practice: M is a sensible default for print. Choose H if a logo covers the center or the surface will get scuffed, wet or handled. Reserve L for codes displayed on a clean screen that will never be damaged, where you are fighting to keep the grid small.
The constraint you actually hit
Nobody runs out of bytes. They run out of millimeters.
The working ratio most people use is roughly 10:1, distance to code width, so a code read from ten feet wants to be about a foot across. At a fixed physical size, every extra version narrows each module, and once modules approach the resolution limit of your printing process or the scanning camera, reads start failing at the edges of the light and angle range. The sizing rules matter far more to whether your code works than any capacity table.
Keeping the payload small
Trim the URL before you encode it, starting with tracking parameters nobody reads. Route long links through a short link so the encoded string stays compact. Where the destination is long or likely to change, a dynamic code keeps the printed pattern sparse permanently, because what gets encoded is a fixed short redirect no matter how sprawling the target URL becomes. If you would rather avoid any dependency, a static code pointed at a short path on your own domain gets you most of the same density.
Contact details deserve a specific warning. A full vCard with a postal address, two phone numbers, a job title and a photo URL will push you into high versions quickly. A link to a contact page encodes in a fraction of the space and stays editable.
Paste your longest real URL into [the generator](/), then paste a shortened version of the same link, and put the two results side by side. The difference in module count is the entire argument, and it takes about thirty seconds to see.
