How much data can a QR code hold? Versions, capacity, and why long URLs break your codes

How much data can a QR code hold?

A QR code can hold up to 7,089 numeric digits, 4,296 alphanumeric characters, or 2,953 bytes of arbitrary data. Those are the ceilings, set by the ISO/IEC 18004 standard, and they only apply at the largest possible code (Version 40) with the lowest level of error correction. In real campaigns you will never get near them, and you should not want to. The interesting question for an agency is not how much a QR code can hold, but how little it should, because the amount of data you encode decides how dense, how fragile, and how large your printed code has to be.

This guide explains where those numbers come from, why a long tracking URL is the most expensive thing you can put in a code, and why the smallest payload almost always wins. If you have ever printed a code that looked like a busy mess of tiny squares and then refused to scan from across the room, this is why.

The short answer, and the catch in it

Here are the absolute maximum capacities, taken from Denso Wave (the company that invented the QR code) and the ISO/IEC 18004 standard it is built on. These are hard specifications, not estimates.

• Numeric (digits only): 7,089 characters
• Alphanumeric (a limited set, see below): 4,296 characters
• Byte / binary (any text, which is what URLs use): 2,953 bytes
• Kanji (Japanese double-byte): 1,817 characters

The catch is that every one of those figures assumes Version 40, the biggest code there is, at error-correction level L, the weakest. Turn up the error correction and the ceiling drops fast. In byte mode the maximum falls from 2,953 bytes at level L to 1,273 bytes at level H, a drop of about 57 per cent. So the honest answer to "how much data can a QR code hold" is "it depends on the version and the error-correction level", and quoting 2,953 bytes as a flat fact is one of the most common mistakes in this topic.

The practical answer is smaller still. A normal web link is a few dozen bytes, and it fits inside one of the tiniest codes there is.

Versions: why a QR code grows

A QR code comes in 40 sizes, called versions. Version 1 is a 21 by 21 grid of modules (a module is one of the little black or white squares). Version 40 is 177 by 177. Each step up adds four modules to each side, so the formula is simple:

modules per side = 21 + 4 x (version - 1)

Version 2 is 25 by 25, Version 5 is 37 by 37, Version 10 is 57 by 57, and so on up to 177. The encoder picks the smallest version that will hold your data at the error-correction level you have chosen. More data forces a higher version, and a higher version means more modules packed into whatever physical space you print the code in. That is the whole mechanism behind a "busy" code: it is not a design choice, it is your payload showing through.

This is a different axis from the physical size of the printed code, which we cover in how big should a QR code be. Version is how many squares there are. Print size is how big each square ends up. The two combine to decide whether a phone can actually resolve the code, which we will come back to.

Encoding modes: your URL is the least efficient kind of data

QR codes do not store characters the way a text file does. The standard defines four encoding modes, and the encoder automatically chooses the densest one that can represent your characters. The mode decides how many bits each character costs, and that is what really drives capacity.

• Numeric mode packs three digits into ten bits, about 3.3 bits per character. The most efficient mode, but it only handles 0 to 9.
• Alphanumeric mode packs two characters into eleven bits, about 5.5 bits each. Its character set is just 45 symbols: the digits, the uppercase letters A to Z, space, and a handful of symbols ($ % * + - . / :). There are no lowercase letters and none of the punctuation a URL relies on.
• Byte mode uses a full eight bits per character and can represent anything, including lowercase letters, ?, =, &, # and _.
• Kanji mode packs Japanese double-byte characters at thirteen bits each.

Here is the part that matters for marketing. A real URL such as https://agency.com/spring?utm_source=poster contains lowercase letters and query-string punctuation, so it cannot use the efficient alphanumeric mode. It drops into byte mode at eight bits per character, the least dense text option there is. Your tracking link is, byte for byte, about the most expensive thing you can ask a QR code to carry. (An all-uppercase link with no query string could squeeze into alphanumeric mode, but nobody writes URLs like that.)

Error correction eats into the budget

QR codes can still be read when they are scratched, smudged, or partly covered, because they carry redundant data using Reed-Solomon error correction. You choose how much redundancy to add, across four levels:

• L (Low): recovers about 7 per cent of codewords
• M (Medium): about 15 per cent, and the usual default
• Q (Quartile): about 25 per cent
• H (High): about 30 per cent

That redundancy is not free. It occupies the same data budget your payload does, so the more error correction you add, the less room is left for content. At Version 40 in byte mode the capacity runs 2,953 bytes at L, 2,331 at M, 1,663 at Q, and 1,273 at H. Moving from L to H more than halves what you can store.

For most printed marketing codes, level M is a sensible default, and you only reach for Q or H when you are placing a logo in the middle or printing onto something that will get knocked about. The logo case is its own balancing act, which we cover in how to put a logo in a QR code without breaking it. One useful precision: the 7 to 30 per cent figures describe the share of codewords the code can recover, not a guaranteed percentage of the physical area you may obscure. They are not a licence to cover a third of the code with artwork.

In the diagram above: (1) a short redirect URL encodes into a low-version, sparse code with large modules that scan easily; (2) the same destination written out in full with UTM parameters needs a much higher version, so the same printed square is filled with far smaller modules; (3) at the same print size, those smaller modules are harder for a camera to resolve, which is where scans start to fail.

What this means when you print

The consequence of all this is direct. More characters force a higher version, a higher version means more and smaller modules, and smaller modules need more resolution, cleaner printing, or a physically larger code to stay readable.

Take a concrete, illustrative example. A short redirect like scn.kit/aB3x9 is around 25 characters and fits in roughly a Version 2 code, a 25 by 25 grid. Write the same campaign out in full, https://agency.com/landing?utm_source=poster&utm_medium=print&utm_campaign=spring25, and you are at about 120 characters, which pushes you to roughly Version 6 or 7, around a 45 by 45 grid. (Exact versions depend on the error-correction level and the encoder, so treat this as illustrative rather than a fixed rule.) That is roughly three times as many modules across the same printed area, so each square is now about 40 per cent of its former width. Print that at the same size on a flyer and it is far more likely to fail, especially when scanned at a distance or under bad lighting. A code that will not scan is almost always one of two things: too small for its density, or too dense for its size. We diagnose the rest of the failure modes in why is my QR code not scanning.

A common rule of thumb for sizing is the 10:1 ratio: a code's width should be about one tenth of the distance it will be scanned from. Ten centimetres away wants a code of at least one centimetre, and a billboard read from ten metres wants a code around a metre wide. That rule is industry guidance, not part of the ISO standard, but it is a reliable starting point. The denser your code, the more generous you need to be with size, which is the clearest argument for keeping the payload short in the first place.

The fix: encode less, not more

Here is the structural problem with long URLs in print. A QR code is a direct encoding of the exact bytes you give it. Change a single character and the entire module pattern is recalculated and looks completely different. That means you cannot shorten or edit a static code once it is printed: the full destination is baked into the dots on the page. If your client's landing page moves, the code is dead.

This is the core reason to use a dynamic QR code. A static code encodes the full, final destination, so a long URL with tracking parameters produces a dense, fragile, large code. A dynamic code encodes only a short redirect, something like scn.kit/aB3x9, and a server resolves that short link to wherever you point it. Because the encoded string is short and never changes, the printed pattern stays low-version, sparse, and stable no matter how long the real destination is or how many times you change it. All the messy UTM parameters live in the redirect, not on the artwork. The full trade-off between the two is in dynamic vs static QR codes, and the practical workflow of repointing a printed code is in change a QR code's destination without reprinting.

There is a neat irony in the marketing claim that "dynamic QR codes hold more data". They hold less encoded data, just a short link, and that is precisely why they work better. The unlimited content lives at the destination, never in the code.

How much do you actually need?

For the overwhelming majority of campaigns: very little. A web link is a few dozen bytes, which fits comfortably inside a Version 1 to 3 code, the small end of the range. You only approach the higher versions if you insist on encoding a long URL directly, or if you embed something genuinely large like a full vCard contact card with multiple fields. Even then you are dealing with hundreds of bytes, not thousands, and nowhere near the 2,953-byte ceiling.

So the right mental model is not "how much can I cram in". It is "what is the shortest string that gets the phone where it needs to go". For a tracked marketing campaign, that string is a short redirect, and everything else, the destination, the tracking, the analytics, sits safely behind it. If you want to see what that redirect lets you measure once people start scanning, that is the subject of QR code analytics.

Frequently asked questions

How many characters can a QR code hold?

At the absolute maximum, a QR code holds 7,089 numeric digits, 4,296 alphanumeric characters, or 2,953 bytes of general text. Those figures require the largest code (Version 40) at the lowest error-correction level (L). Raise the error correction and the limits drop substantially, to as low as 1,273 bytes at level H. Real-world codes hold far less, usually a few dozen to a few hundred characters.

What is the maximum URL length for a QR code?

A URL is stored in byte mode at eight bits per character, so the hard ceiling is 2,953 characters at Version 40, level L. That is purely theoretical. In practice you want a URL well under about 100 characters so the code stays a low version and prints cleanly. The most reliable approach is to encode a short redirect of 20 to 30 characters and keep the long destination behind it.

Does a longer URL make a QR code harder to scan?

Yes. A longer URL forces a higher version, which packs more and smaller modules into the same printed area. Smaller modules need more camera resolution, better print quality, or a larger physical code to read reliably. This is the single most common cause of a code that looks "busy" and fails to scan at a distance.

What are QR code versions?

Versions are the 40 standard sizes of a QR code, from Version 1 at 21 by 21 modules to Version 40 at 177 by 177. Each version up adds four modules per side. The encoder automatically selects the smallest version that fits your data at your chosen error-correction level, so more data means a higher version.

Does error correction reduce QR code capacity?

Yes. Error correction adds redundant data that shares the same budget as your content, so higher levels leave less room. In byte mode at Version 40, capacity falls from 2,953 bytes at level L to 2,331 at M, 1,663 at Q, and 1,273 at H. The four levels recover roughly 7, 15, 25 and 30 per cent of codewords respectively.

Can a QR code store an image or a whole web page?

No. Even at the maximum of 2,953 bytes, there is nowhere near enough room for an image or a web page. A QR code stores a link to that content, not the content itself. This is why every practical use, from a menu to a video to a contact card, points to a hosted destination rather than embedding the file.

Why does my QR code look so busy and dense?

Density is a symptom of how much data you encoded. A long URL, especially one with UTM tracking parameters, forces a higher version with many small modules, which reads as a busy, cluttered code. Shorten the payload, ideally to a short redirect, and the same code becomes sparse and far easier to scan.

Do dynamic QR codes hold more data than static ones?

No, and the opposite framing is more accurate. A dynamic code encodes only a short redirect link, so it holds less data than a static code carrying a full URL. That is exactly why it stays small and scannable. The "unlimited" content a dynamic code seems to offer lives at the destination, which you can change at any time, not inside the printed pattern.

The short version

A QR code can technically hold up to 2,953 bytes, but that ceiling is a distraction. Capacity drops with higher error correction, real URLs are stored in the least efficient mode, and every extra character pushes the code to a higher version with smaller, more fragile modules. The practical lesson is the reverse of the usual question: encode as little as possible. A short redirect of a couple of dozen characters keeps your code sparse, robust, and easy to scan, and it lets you change the destination later without reprinting. Before you send any code to print, look at the length of the string inside it. If it is a long tracking URL, swap it for a dynamic short link and let the redirect carry the weight.