Anyone who has generated QR codes has run into this puzzlement: the content isn't long, yet the code comes out so dense it's hard to make out — while someone else's code, scanning to quite a long URL, looks much sparser.
The reason is that a QR code has four different encoding modes internally. Different kinds of characters take different channels, and the space they occupy can differ several-fold. Understand that, and you can control a code's density deliberately.
Four encoding modes: the same information, very different sizes
QR codes provide dedicated encodings for different character types, each with a different "packing efficiency":
| Mode | Characters | Bits per character | Relative efficiency |
|---|---|---|---|
| Numeric | 0-9 | about 3.33 bits | Highest (40% saved) |
| Alphanumeric | 0-9 A-Z space $%*+-./: | about 5.5 bits | High |
| Byte | Everything else (incl. Chinese) | 8 bits | Baseline |
| Kanji | Shift-JIS kanji | 13 bits | Slightly better for common CJK |
The key point: one Chinese character takes 3 bytes in UTF-8, which is 24 bits, whereas one Latin letter takes 1 byte (8 bits). So for the same "20 characters", Chinese needs 480 bits and English only 160 — a 3× difference.
That is the most direct reason Chinese QR codes come out denser.
Kanji mode helps a little, with conditions
The QR standard includes a dedicated "kanji mode" where each character takes only 13 bits — nearly half of byte mode's 24. Sounds great, but it has a hard restriction: it only supports characters that exist in Shift-JIS encoding.
Shift-JIS is a Japanese encoding, and the set of characters it covers doesn't fully overlap with GB2312 or Unicode. So:
- Many common Chinese characters hit it and save space;
- Some simplified characters, rare characters and all non-Chinese characters (Chinese punctuation, emoji) fall back to byte mode;
- The generator must switch intelligently between the two modes, or very little is saved.
In practice, many generators use byte mode throughout to guarantee compatibility and correctness. The result is that Chinese content is all counted at 24 bits per character, and the code comes out dense.
One practical tip along the way: Chinese punctuation is also 3 bytes. The full-width full stop 。, comma ，and enumeration comma 、are all full-width and each takes 3 bytes. If your content is punctuation-heavy, try switching to half-width punctuation to reclaim some space.
Error correction level: redundancy buys tolerance
The other place a QR code spends space is the error correction code. It uses Reed-Solomon coding to add redundancy to the data, so that even if part of the pattern is soiled, the original content can still be recovered. Four levels:
- Level L: about 7% redundancy, recovering roughly 7% damage
- Level M: about 15% (the most common default)
- Level Q: about 25%
- Level H: about 30%, the highest tolerance
That redundancy occupies real space. At version 10 (57×57 modules), level L holds 271 bytes while level H holds only 119 — nearly 56% less.
So if your code only needs to be scanned off a screen, L or M is plenty, and the pattern will be noticeably sparser and easier to scan. Only reach for Q or H when the code must be printed on something that may wear, or when a logo goes in the middle.
That is exactly how a centre logo works: the covered area is treated as damage and recovered from level H's 30% redundancy. Put a logo on an L-level code and it essentially won't scan.
Version: the "size tier" of a QR code
There are 40 versions in all, and version n has an edge length of 4n + 17 modules:
- Version 1: 21 × 21
- Version 2: 25 × 25
- Version 10: 57 × 57
- Version 20: 97 × 97
- Version 40: 177 × 177
Capacity climbs from a few dozen bytes at version 1 up to 2,953 bytes at version 40 (level L, byte mode). The generator picks the smallest version that fits your content.
Two things are worth noting here:
- The module count grows with the square of the edge. Going from version 20 to 40 less than doubles the edge but multiplies the module count by 3.3. So a high-version code ends up with very small individual modules.
- Modules that are too small won't scan. In theory each module needs at least 2 to 3 pixels for stable recognition. If your content pushes the version above 20 and the printed size is modest, it may well be unscannable in practice.
Practical conclusions: make your QR code easier to scan
To get a code that's both clear and easy to scan, optimise in this order:
- Shorten the content. This is the most effective lever by far. Shorter URLs, fewer parameters, and a short-link redirect in the middle are the usual approach. Halve the content and the version may drop several levels.
- Lower the error correction level. Use L or M for screen display rather than reflexively choosing H. Higher levels are only worth it when a logo must be embedded or the code is printed on a wear-prone material.
- Preserve the quiet zone. A QR code needs a clear margin at least four modules wide on all sides — the quiet zone — which the recognition algorithm uses to find the code's edge. Cropping it away is the number one cause of scan failures, more common even than blur.
- Allow enough pixels. At least 4 pixels per module is the safe target, so version 10 (57 modules) needs at least 228 pixels of width.
- Don't use a small raster image. If you must embed a code in a picture, export at a sufficient resolution, or use a vector format (SVG) so scaling doesn't blur it.
How to tell how dense your code is
Two approaches:
First, watch the version number the tool reports when you generate — the lower the version, the easier it scans. If you use the QR code generator, it shows the version and byte count your content occupies, so you can edit the content and watch the version change, and get a feel for "removing these few characters drops it a version".
Second, take an existing code to the QR code decoder and check its version, error correction level and content type. If you find a supposedly long piece of content sitting in a low version, the content probably contains a short link.
Both tools run locally in your browser; the images you generate and upload never pass through a server.
In one sentence
A QR code's density = content bytes ÷ encoding efficiency + error correction redundancy. Chinese counts at 3 bytes, and Chinese punctuation too, which is why Chinese codes are naturally denser. To make one sparser, the most effective moves are less content and a lower correction level — not a different generator.