# How much data fits in a QR code? Capacity, length and density

> A QR code can hold up to a few thousand characters at most, but practical codes stay far shorter. Here is what determines capacity and how to keep codes scannable.

A QR code can technically hold up to a few thousand characters of text at the lowest error correction level, but that is a ceiling, not a target. In practice, the more data you pack in, the denser and harder-to-scan the pattern becomes, so the most reliable codes usually contain a short URL or a few dozen characters. This article explains what determines capacity, why practical codes stay short, and how to keep even data-heavy codes scannable.

## What actually determines how much a QR code can hold

Three factors set the maximum capacity of any QR code: its version, its encoding mode, and its error correction level. Change any one of them and the amount of data that fits changes too.

**Version.** QR codes come in 40 versions. Version 1 is a 21-by-21 grid of modules; each step up adds four modules per side, so version 40 is a 177-by-177 grid. Bigger grid, more room for data. Most codes you see in the wild are somewhere between version 2 and version 10.

**Encoding mode.** The same grid can store different kinds of data at different densities. The three most common modes are:

- **Numeric:** digits only (0–9). The most compact mode.
- **Alphanumeric:** uppercase letters, digits and a handful of symbols (space, $, %, *, +, -, ., /, :). Less compact than numeric.
- **Byte (binary):** any byte values, which is how lowercase letters, accented characters and most URLs get encoded. The least compact of the three.

A lowercase letter in a URL forces byte mode, so a URL with lowercase text holds roughly half as many characters as the same length of pure digits would. That is worth knowing before you try to squeeze a long link into a small code.

**Error correction level.** QR codes deliberately duplicate some of their data so they can survive damage. There are four levels — L, M, Q, H — where L dedicates the least space to redundancy and H the most. Higher correction means the code still scans with a corner torn off or a logo overlaid, but it also means less room for your actual data. The same content that fits in a version 5 code at level L might need a version 7 or 8 at level H.

These three factors interact. There is no single "capacity of a QR code" — only the capacity of a specific version, mode and correction level combination.

## The rough numbers, without the tables

Exact capacity figures live in lookup tables defined by the ISO/IEC 18004 standard, which is the international specification for QR codes. You do not need those tables to make good decisions, but a few rough anchors help.

At the top end, a version 40 code at error correction level L can hold around 7,000 numeric characters, roughly 4,000 alphanumeric characters, or around 2,900 byte-mode characters. Those are the headline maximums people sometimes quote.

At the other end, a small version 3 code at level M holds on the order of 60–70 byte-mode characters — enough for a medium-length URL, not much more.

The useful takeaway is the shape of the curve, not the exact figures. Capacity roughly doubles every few versions, and error correction eats a meaningful slice of it. If you need to store a paragraph of text, you will end up with a large, dense code. If you need to store a short link, a modest version works fine and scans easily.

## Why more data means a harder-to-scan code

Every extra character adds modules to the grid. A version 1 code has 441 modules; a version 10 code has 573 of them per side... more precisely, 57 by 57, which is 3,249 modules. Each module is a black or white square, and the scanner's job is to resolve each one cleanly.

Density causes trouble in two directions:

- **On paper or screens at fixed size.** A code printed at 2 centimetres has far smaller individual modules if it is version 8 than if it is version 3. Small modules blur when printed cheaply, photographed at an angle, or displayed on a low-resolution screen. The result is a code that works on your monitor and fails on the printed flyer.
- **At a distance.** A rule of thumb many practitioners use is that the scanning distance should be no more than about ten times the code's width — and denser codes effectively shorten that ratio, because the modules need to appear larger to the camera.

There is also a human factor: dense codes look intimidating and print smaller-looking at the same physical size, which slightly reduces the number of people who bother to scan them.

The practical conclusion: capacity is not a resource to maximise. The best QR code is the least dense one that does the job.

## The single biggest win: shorten the URL

Most QR codes in everyday use encode a URL, and URLs are usually the longest thing people try to encode. Trimming and shortening the URL is the most effective density reduction available.

Start with what you control:

- Use the shortest domain you have. `shop.example.com/p/sale` beats `https://www.shop.example.com/products/summer-sale-2025.html` in every way.
- Drop `https://` if your generator allows it — most scanner apps handle a bare domain, though including the scheme guarantees the scanner opens it as a link.
- Cut path cruft. If a page is reachable at a shorter path, use it.

If you cannot shorten the destination itself, use a URL shortener. A shortener turns a 200-character link into something like 25 characters, which can take a code down several versions. The trade-offs are real, though: you now depend on the shortener staying online, and some scanners or users distrust shortened links because they hide the destination. If you use one, pick a service you expect to still exist in five years, or better, use a shortener on a domain you own.

## Dynamic QR codes: change the destination without reprinting

A related approach is the dynamic QR code: the code encodes a short redirect URL, and the redirect target can be changed later. The printed code never changes; only the destination behind it does.

This solves two problems at once. First, the encoded content is short, so the code stays small and easy to scan. Second, you can fix a broken link or point an old poster at a new campaign without reprinting anything.

The trade-off is the same dependency as a shortener, plus one more: a dynamic code only works while the redirect service is running. A static code with the full URL baked in dies when your website changes, but it never depends on a third party. Choose based on which failure you can live with. For anything long-lived and critical — a sign at a physical location, product packaging — a short, static URL on your own domain is often the sturdier choice.

## Trim tracking parameters before encoding

Marketing URLs often carry long strings of tracking parameters: `?utm_source=poster&utm_campaign=summer&gclid=...`. These can double or triple a URL's length and push a comfortable code into dense territory.

Before encoding, ask whether the parameters need to be in the code at all. Often they do not:

- If you need per-channel analytics, a dedicated short path (`example.com/poster`) is shorter and gives you the same attribution through your own analytics.
- Click-identifiers like `gclid` are generated per click and are meaningless when baked into a printed code — anyone who scans it shares the same ID, which defeats their purpose anyway.
- Some sites ignore unknown parameters; others may treat them as part of the canonical URL. Test the trimmed URL in a private browser window to confirm it still lands on the right page.

Trimming parameters is free, needs no third party, and frequently removes more characters than a shortener would.

## Error correction: the trade-off in both directions

Error correction is not a settings knob to max out. It is a trade between resilience and density, and the right level depends on where the code lives.

- **Level L** gives the most data capacity and the least redundancy. Fine for screens, where nothing scratches the code.
- **Level M** is the common middle ground and the default in many generators. A sensible choice for print where the code sits on clean paper.
- **Level Q and H** survive serious damage or deliberate decoration — a logo placed in the centre, printing on textured material, codes on factory floors. They cost capacity: the same content needs a larger, denser grid.

A common mistake is choosing level H "to be safe" and then printing the resulting dense code at a size too small for it. A high correction level cannot save a code whose modules have blurred into grey mush. If scannability is the priority, a lower correction level with a less dense pattern usually beats a higher level with a denser one. Reserve Q and H for cases with a known physical risk, such as a logo overlay.

## Test the code at its real printed size

The final step, and the one people skip: test the code the way your audience will encounter it.

1. Generate the code, then print or render it at the exact final size — not enlarged "for testing". A code that scans at 10 cm on your desk may fail at 2 cm on a business card.
2. Scan it with more than one phone, from a realistic distance and angle, under realistic lighting. Glossy paper, screen glare and curved surfaces all degrade scanning.
3. If it is going on a screen, view it at actual size on a small phone display, not just on your desktop monitor.
4. If it is going into mass print, get a proof from the printer and scan the proof, because print quality and paper stock affect module sharpness.

If the code fails at its real size, do not reach first for a higher error correction level. Reduce the data: shorten the URL, trim parameters, or switch to a dynamic code. Shrinking the content almost always fixes density problems better than any setting change.

## Conclusion

A QR code's capacity is set by its version, encoding mode and error correction level, with true maximums in the low thousands of characters defined by the ISO/IEC 18004 standard. But capacity is a ceiling, not a goal. The most scannable codes carry the shortest content that does the job: a trimmed URL, tracking parameters removed, a shortener or dynamic redirect when the destination is genuinely long, and an error correction level matched to the physical risk. Whatever you encode, test the finished code at its actual printed size with a real phone. Short content, modest density, verified at print size — that is the whole formula.