How Many Characters Can a QR Code Hold? Data Capacity Explained

At its absolute maximum — QR version 40, error correction level L — a single QR code can hold 7,089 numeric digits, 4,296 alphanumeric characters, 2,953 bytes of binary or UTF-8 data, or 1,817 Kanji characters.

Those are the ceilings defined by the ISO/IEC 18004 standard, and they are almost never the number you should design to. A code carrying anything close to 2,953 bytes is a 177×177 module monster that needs to be printed very large and scanned very close to be readable at all. The practical limit for anything printed and scanned by a customer's phone is closer to a few hundred characters — and for a code on a hoarding, closer to a few dozen. This guide covers both the real ceilings and the real working limits.

There is no single "QR code character limit" because capacity is set by three variables interacting:

• Version (the grid size). QR codes come in 40 versions, from version 1 at 21×21 modules to version 40 at 177×177 modules, stepping up by 4 modules per side each time. A bigger grid holds more data. Encoders normally pick the smallest version that fits your data automatically.
• Encoding mode. The standard defines four modes, and each packs characters at a different efficiency: numeric (digits only, most efficient), alphanumeric (digits, uppercase A–Z and nine symbols), byte (anything, including lowercase and UTF-8 — least efficient per character), and Kanji. A URL almost always falls into byte mode because of its lowercase letters and punctuation.
• Error correction level. L, M, Q and H reserve progressively more of the symbol for recovery data, leaving progressively less for your content. Our error correction levels guide covers that trade-off in full.

The ceiling for each combination of encoding mode and error correction level, at the largest possible QR version:

Read this as an upper bound, not a target. Note how much capacity error correction costs: the same physical grid holds 2,953 bytes at L and only 1,273 at H.

At the other end, the smallest QR code — version 1, a 21×21 module grid — holds remarkably little:

This matters more than it looks. A version 1 code is the sparsest, largest-module, easiest-to-scan QR code you can make — and at Q, it holds just 11 bytes. That is the real reason short links exist: keeping a payload tiny is what keeps a code at a low version, and low versions are what scan reliably from a distance on a cheap camera.

Every character you add pushes the code toward a higher version, and every version step adds four modules per side. Print size stays the same, so each module shrinks. The consequences compound quickly:

• Scan distance falls. Smaller modules need a closer camera. A dense code on a standee that people scan from two metres away simply will not read. Our scan distance guide covers the arithmetic.
• Print tolerance falls. Small modules blur together on low-DPI printing, on absorbent stock, on corrugated packaging and on thermal labels — the exact materials most Indian print runs actually use.
• Cheap cameras fail first. A dense code that reads instantly on a flagship phone can fail repeatedly on the entry-level Android a large share of your customers are carrying.

A useful working rule: for anything printed and scanned in the field, keep the payload under about 300 characters, and ideally far less. For outdoor or long-distance placements, aim for under 50.

Rough payload sizes for the QR types people actually create:

• A SMLLR dynamic short link: roughly 25–30 characters. Comfortably a low-version code with large modules, regardless of how long the destination URL is.
• A static URL with UTM parameters: commonly 120–250 characters, and easily more. This is where most print failures originate.
• A Wi-Fi config string (WIFI:T:WPA;S:NetworkName;P:Password;H:false;;): typically 40–80 characters depending on SSID and password length.
• An SMS payload (sms:+919999999999?body=...): 20 characters plus the message body.
• A vCard contact card: 150–400+ characters depending on how many fields you include — the most common cause of an accidentally dense personal QR code.
• A UPI payment string (upi://pay?pa=...&pn=...&am=...): typically 50–120 characters.

Only the first of these is immune to the length problem, because a dynamic code's payload never changes no matter what sits behind it.

If your content is too long, the options in order of how well they actually work:

1. Use a dynamic short link. This is the real answer in almost every case. Instead of encoding a 250-character URL, encode a ~25-character SMLLR link and let the redirect carry the rest. The code drops several versions, the modules get much larger, and you gain the ability to change the destination later without reprinting.
2. Move the content to a page instead of into the code. A vCard, a full address, a menu, a product spec sheet — none of these belong inside the pattern. Put them on a page and point the code at it.
3. Use the right encoding mode. If your data is genuinely all digits, keeping it numeric rather than byte more than doubles capacity for the same grid. Uppercase-only alphanumeric is similarly more efficient than mixed case.
4. Lower the error correction level. Dropping from H to Q frees meaningful capacity — but only do this when the code will not be damaged, covered or weathered, since you are spending your damage budget to buy space.

Only consider the last one after the first two, because a shorter payload improves capacity and scan reliability at once, while a lower level trades one for the other.

Every dynamic QR code you create on SMLLR encodes a short redirect link, not your destination. That single property is what keeps printed codes at low versions with large, forgiving modules — and it is why the same physical code can point at a 40-character landing page today and a 300-character campaign URL with five UTM parameters next month without anything on the printed side changing.

If you are working with static codes for a reason — an always-static type like a vCard, plain text or a Wi-Fi config, which must encode raw content rather than a URL — then capacity really is a hard design constraint, and the tables above are the ones to plan against. Our technical anatomy of a QR code post explains why those types can never be dynamic.

Create your QR code on SMLLR and check the generated code's density in the preview before you commit to a print size.