The Four Encoding Modes and Their Capacities
The QR code standard defines four encoding modes, each optimized for a different character set. The mode with the fewest bits per character gives the highest capacity for compatible data.
Numeric Mode - Up to 7,089 Characters
Numeric mode handles only the digits 0 through 9. It encodes groups of three digits into 10 bits, achieving an average efficiency of about 3.33 bits per character. This is the most efficient mode available. At Version 40 with error correction level L (the minimum), numeric mode can hold 7,089 digits.
Practical use cases include: phone numbers, product serial numbers, numeric codes, PIN entry systems, and coupon codes that happen to be purely numeric.
Alphanumeric Mode - Up to 4,296 Characters
Alphanumeric mode supports digits 0-9, uppercase letters A-Z, and nine special characters: space, $, %, *, +, -, ., /, and :. Pairs of characters are encoded into 11 bits. At Version 40, level L, the capacity is 4,296 characters.
Note the restriction to uppercase only. A URL like HTTPS://EXAMPLE.COM could technically use alphanumeric mode (since the scheme and domain can be uppercase), but any path containing lowercase letters would force the encoder into binary mode for that segment.
Binary (Byte) Mode - Up to 2,953 Bytes
Binary mode encodes any byte value - the full 256 values of an 8-bit byte. Each character costs 8 bits. At Version 40, level L, the capacity is 2,953 bytes. For standard ASCII text (which covers all English characters, punctuation, and common symbols), this means 2,953 characters. For UTF-8 encoded text with non-ASCII characters, some characters may require 2, 3, or even 4 bytes, reducing the effective character count.
Binary mode is what most QR code generators use for URLs and general text, because real-world URLs contain lowercase letters and slashes that are outside the alphanumeric character set.
Kanji Mode - Up to 1,817 Characters
Kanji mode is specific to the Shift JIS encoding used for Japanese. Each double-byte character is encoded in 13 bits. At Version 40, level L, the capacity is 1,817 Kanji characters. This mode provides efficient encoding for Japanese and Chinese text in the Shift JIS character set.
How Error Correction Level Reduces Capacity
QR codes offer four error correction levels, and choosing a higher level directly reduces the amount of data you can store because more of the code's modules are used for redundant error correction data rather than actual payload.
- Level L (Low) - Recovers 7% of data. Maximum capacity. Use for clean print and digital contexts.
- Level M (Medium) - Recovers 15% of data. Capacity reduced to roughly 80% of Level L.
- Level Q (Quartile) - Recovers 25%. Capacity reduced to roughly 65% of Level L.
- Level H (High) - Recovers 30%. Capacity reduced to roughly 55% of Level L. Best when adding a logo or expecting physical damage.
For a typical URL like https://example.com/page (about 25 characters), the difference barely matters - any error correction level at a low version handles it easily. For maximum data payloads approaching the theoretical limits, every level of added error correction noticeably reduces capacity.
How Version Affects Module Count and Capacity
QR code versions run from 1 to 40. Each version is a square grid where the side length is (4 × version) + 17 modules. Version 1 is 21×21 (441 modules). Version 10 is 57×57 (3,249 modules). Version 40 is 177×177 (31,329 modules).
As version increases, more modules are available for data - but more modules are also consumed by alignment patterns, timing patterns, and error correction codewords. The net data capacity still increases substantially with version, but not as fast as the raw module count suggests.
Key version milestones for binary mode at level M (a common practical choice):
- Version 1 - 14 bytes. Enough for a short identifier or very short URL.
- Version 5 - 85 bytes. Enough for a typical HTTPS URL.
- Version 10 - 213 bytes. A full URL with long path and query parameters.
- Version 20 - 535 bytes. A substantial block of text.
- Version 40 - 2,331 bytes. Close to the theoretical maximum at this level.
In practice, most QR codes generated for marketing and consumer use are Version 3-7, holding 50-150 bytes, which is plenty for any URL.
Why URLs Are Almost Always the Better Choice
Given these capacity constraints, it is worth understanding why pointing to a URL beats encoding raw content directly in most scenarios. Consider these comparisons:
- A typical product description might run 500-2,000 words - millions of bytes, far beyond any QR code.
- Even a single short paragraph of 300 characters produces a Version 6+ code at Level M, which requires meaningful print size to scan reliably.
- A URL pointing to that same content might be just 35 characters - a Version 2 code at any error correction level, scannable at thumbnail size.
Beyond the density advantage, URLs are updatable. If you print 10,000 brochures with a QR code pointing to a URL, you can update the page at that URL any time. If you encode the text directly and need to change one word, you need to reprint everything. Tools like Vexifa QR Code let you generate URL-based codes that stay small and scannable no matter how much content you put on the destination page.
Practical Examples of What Fits at Each Capacity Level
To make capacity concrete, here are real examples of what fits at various data sizes in binary mode at Level M:
- 14-20 bytes - Phone number, short numeric code, WiFi network name
- 40-60 bytes - Short URL (e.g., https://yourbrand.com)
- 80-120 bytes - URL with UTM parameters for campaign tracking
- 150-200 bytes - vCard with name, phone, and email only
- 300-500 bytes - Full vCard with multiple fields, WiFi credentials
- 1,000+ bytes - Multi-field data, short paragraphs of text
- 2,953 bytes max - About 500 words of plain English text - a dense, high-version code requiring careful printing
The Density Trade-off: Data vs. Scannability
High data density comes at a real cost to scannability. As a QR code increases in version, the individual modules become smaller relative to the total code size. When printed at a fixed physical size, this means each module is physically smaller and harder for a camera to resolve - especially at distance, in poor lighting, or on a slightly blurry print.
The practical rule: keep your QR code data as short as possible. Every character you remove allows the generator to use a lower version, producing larger modules that are more robust in challenging real-world conditions. Shorten URLs with a redirect, remove tracking parameters you can add server-side, and strip unnecessary prefixes where possible.
Frequently Asked Questions
What is the maximum amount of text a QR code can hold?
The absolute maximum is 7,089 numeric digits or 4,296 alphanumeric characters (uppercase + numbers + limited symbols) at error correction level L. For general text including lowercase letters, the binary encoding mode allows up to 2,953 bytes at Level L - roughly 2,953 ASCII characters or about 500 words of English text. Higher error correction levels reduce these maximums significantly.
Does adding a logo reduce data capacity?
Adding a logo does not change the amount of data encoded in the QR code - the same data is stored regardless. However, the logo physically covers some modules, which must be reconstructed via error correction. This consumes error correction capacity, so it is important to use Level Q or H when adding a logo. If the logo is too large and the error correction is insufficient, the code will fail to scan.
Why are URLs better than storing all text in a QR code?
A URL is typically 30-80 characters and produces a small, simple low-version QR code that scans reliably even when printed small or in imperfect conditions. Storing equivalent content as raw text would require hundreds or thousands of characters, resulting in a dense high-version code that needs to be printed large and scanned carefully. URLs also allow you to update the content at any time without reprinting the physical code.
What happens if I try to put too much data in a QR code?
A QR code generator will automatically increase the version to accommodate more data, up to the maximum of Version 40. If the data exceeds the maximum capacity - even at Version 40, Level L - the generator should return an error indicating the data is too large. There is no way to exceed the ISO 18004 standard's defined limits; the solution is to shorten the data or use a URL instead.