How much data can a QR code hold?

The five-minute version

1. The quoted ceilings — 7,089 digits, 4,296 alphanumeric, 2,953 bytes — all describe one enormous code nobody prints. Ignore them.
2. Your real budget is set by how big the code will be printed. At about 2 cm you can afford a 60–100 character URL; at 1 cm, closer to 25.
3. A version is just the grid size: version 1 is 21 × 21, and each version up adds four modules per side. More data pushes the version up and each square down.
4. Error correction is paid out of the same grid. Going from level M to level H typically costs you a version or two, which means a bigger print for the same content.
5. Over budget? Encode a short path on a domain you own, split the object into two codes, or print bigger. Those are the only three moves.

What a version is, since every guide assumes it

Advice about QR codes leans on the word “version” constantly — this site’s guides included, in sentences like “a registration ID is a version 1–2 code, while a long URL pushes it to version 5–6” — and almost never says what one is. It is not a software release and it is not a quality setting. The version is the size of the grid. Version 1 is 21 × 21 modules. Every version up adds four modules to each side: version 2 is 25 × 25, version 6 is 41 × 41, version 15 is 77 × 77, and version 40, the last one, is 177 × 177.

You do not choose it. The generator takes your content and your error-correction level, and picks the lowest version the data fits in. So the version is an output — a readout of how much you asked for. That is what makes it worth understanding: it is the one number that translates “my URL got longer” into “my code now needs to be printed 6 mm wider”.

Why the famous numbers are the wrong numbers

Every capacity table on the internet ends with the same three figures, and they all describe the same object: a version 40 symbol at the weakest error correction. That is a 177 × 177 grid. Ordinary commercial print holds a module down to roughly 0.4 mm before the squares start bleeding into each other, which puts that code at about 71 mm across — and that is only the reproduction floor. A phone camera also has to resolve 177 distinct columns in whatever slice of its frame the code occupies, held by hand, so in practice a code that dense wants to be larger still and scanned deliberately.

So “4,296 characters” is a fact about the format, not a permission. The usable question is the inverse one, and it is the one nobody answers: at the size this thing is actually going to be printed, how many characters do I get?

Your actual budget, by printed size

The table below is byte mode at error-correction level M, which is what almost every generator defaults to and what a normal mixed-case URL uses. The width is the smallest the symbol can be printed at before the modules drop under 0.4 mm; the quiet zone adds four modules of clear white on every side on top of that.

• Up to 26 characters — version 2, 25 × 25 grid, prints down to 10 mm. A bare domain, a short ID, a table number.
• Up to 62 characters — version 4, 33 × 33, down to 13 mm. A short URL with a one-word path. This is the sweet spot for anything small.
• Up to 106 characters — version 6, 41 × 41, down to 17 mm. A normal URL, or a short one carrying a tracking tail.
• Up to 213 characters — version 10, 57 × 57, down to 23 mm. A long URL with query parameters, or a WiFi credential with a long password.
• Up to 412 characters — version 15, 77 × 77, down to 31 mm. A full vCard with name, title, two phone numbers, email and address.
• The ceiling — version 40, 177 × 177, 2,331 characters at level M, needing 71 mm and a patient scanner.

Read it in whichever direction you have a constraint in. If the content is fixed, the table gives you a minimum size. If the size is fixed — a 15 mm corner of a label, a 20 mm space on a business card — it gives you a character budget, and going over it does not produce a warning, it produces a code that looks fine on screen and fails on paper.

This is only half of the size question, and it is the half that gets forgotten. Density sets one floor; scanning distance sets another, via the rule that a code should be about a tenth of the distance it is read from. The size guide owns that calculation. Work out both numbers and print at the larger — a sparse code on a poster is governed by distance, a dense code on a label by density.

Error correction spends the same budget

A QR code carries redundant data so it still reads when part of it is dirty, creased or covered. There are four levels — L, M, Q and H, recovering roughly 7, 15, 25 and 30 percent of the symbol — and the redundancy lives in the same grid as your content. At the maximum version, level L holds 2,953 bytes and level H holds 1,273: the strongest protection costs well over half the capacity.

At the sizes you will actually use, that shows up as versions rather than lost characters. A 90-character URL fits a 33 × 33 grid at level M and needs 41 × 41 at level H — the same content, 4 mm wider at the print floor. Which is the honest framing of the logo tax: a logo in the middle is only survivable because level H can lose that area, so choosing to put one there is choosing to print bigger. The design guide has the limits on how much of the centre you can cover. Level M is the right default for clean indoor print; go to Q or H for packaging, outdoor signage, anything that will be handled — and budget the size increase at the same time, not after.

What quietly inflates a payload

• Tracking tails. An eleven-character ?utm_source= pair can push a code up two versions, partly through length and partly because ?, = and & force the whole string into byte mode. If you need attribution on a printed code, put a distinct short path on your own domain and record the parameters server-side, where they cost nothing.
• Mixed case. QR has a compact alphanumeric mode — digits, uppercase A–Z, space and $ % * + - . / : — at about 5.5 bits per character against 8 for byte mode. An all-uppercase URL can drop a version. Domains are case-insensitive so uppercasing the host is free; paths usually are not, so only do it if your server really serves that path.
• The scheme. https://www. is twelve characters before you have said anything. Most scanners and servers cope fine without the www., and some generators can omit the scheme entirely for a plain domain.
• vCard fields. Every optional line — second address, fax, note, birthday — is stored in the pattern forever. Cut to name, one number, email, website and you drop several versions.
• WiFi passwords. A long random passphrase is stored verbatim in a WiFi code, and the network name and security type ride along with it.
• Non-Latin characters. Accents, curly quotes and emoji are multi-byte in UTF-8, so they cost two to four times a plain letter. An em dash in a vCard note is three characters of budget.

Three moves when you are over budget

1. Put the length behind a URL you own. Serve a short path — example.com/m — and let your own server redirect to the long destination. The code stays a version 2, and the long URL becomes editable rather than printed. This is the cluster’s standard answer and it works here for the same reason it works everywhere else.
2. Split the object. If one printed thing is carrying two errands — a menu and a review request, a listing and a contact card — two sparse codes almost always beat one dense one, and they can have different lifespans. The real estate guide works through the case in detail.
3. Print bigger. Unglamorous, and often correct. The table above tells you exactly how much bigger; going from 13 mm to 17 mm is usually a layout conversation, not a redesign.

Capacity is the last honest argument for a dynamic code, and it does not survive contact with the first move. A paid redirect service does keep your code sparse — that part is true. But a short path on a domain you own is equally sparse and equally editable, without handing the destination to a landlord whose subscription can lapse. The static-versus-dynamic guide concedes there are cases where the destination genuinely has to change; this is not one of them, because the thing you needed was never the redirect, it was the shortness.

Before you commit it to a print run

1. Read the version off the generator once the content is final. If it is above 10 for a URL, something in the string is longer than it needs to be.
2. Do the arithmetic in the direction of your constraint — grid modules × 0.4 mm for the density floor, scanning distance ÷ 10 for the distance floor, print at whichever is larger.
3. Scan the printed proof, not the screen. Density problems are exactly the class of failure that looks perfect at 100% zoom and dies on paper; the testing guide has the sequence, and a dense code deserves the awkward-angle and low-light passes rather than one clean scan.