Kanji mode explained — 13 bits per character

Why a dedicated mode exists

QR codes were invented at Denso Wave in 1994 to label car parts in Japanese factories. Japanese text in the encoding of the day — Shift-JIS — takes two bytes per character, which in byte mode is 16 bits. The designers noticed the double-byte space is far from full: the roughly 8,000 defined characters need only 13 bits (2¹³ = 8,192). Kanji mode exploits that headroom, cutting Japanese text costs by 19% versus Shift-JIS bytes and — more relevantly today — by 46% versus UTF-8, where CJK characters take three bytes (24 bits).

The packing algorithm

Each character must be a double-byte Shift-JIS value in one of two ranges. The encoder:

1. Subtracts the range offset:
   • 0x8140–0x9FFC → subtract 0x8140
   • 0xE040–0xEBBF → subtract 0xC140
2. Repacks the two result bytes as: (high byte × 0xC0) + low byte.
3. Stores the result in 13 bits.

The multiplier 0xC0 (192) works because after the subtraction the low byte never exceeds 191 — the two bytes collapse into one integer with no gaps wasted. The segment header is the mode indicator 1000 plus a character count (8 bits at versions 1–9, 10 at 10–26, 12 at 27–40).

Characters outside those ranges — ASCII, half-width kana, anything non-Japanese — do not qualify, so real-world Japanese payloads typically mix segments: byte or alphanumeric mode for the URL part, kanji mode for the text part, each switch costing a fresh header.

When generators actually use it

Rarely. Kanji mode's practical position in 2026:

• Most Western libraries never emit it — including UseQR's encoder, which selects among numeric, alphanumeric and byte modes only and carries Japanese text as UTF-8. Japanese-market libraries and some banking/ticketing systems still produce it.
• Decoder support is good but not universal. Phone cameras and ZXing-family libraries handle kanji mode fine; minimal embedded decoders sometimes do not, and the output must then be transcoded from Shift-JIS.
• The interoperability current runs against Shift-JIS. The wider software world treats UTF-8 as the one encoding; a kanji-mode payload hands every consumer a legacy character set to deal with — the same trap described in UTF-8 and Unicode in QR codes.

The honest trade: kanji mode is worth its density only when the payload is substantially Japanese text and the code is near a version boundary and you control or have tested the readers. A 100-character Japanese message is ~1,300 bits in kanji mode against ~2,400 as UTF-8 — a real saving that can drop the symbol a version or two. For a URL with a few Japanese query parameters, it buys nothing but risk. Whichever route you take, verify the decoded text round-trips exactly.

FAQ

What is kanji mode in a QR code?

An encoding mode that stores one double-byte Shift-JIS character in 13 bits instead of 16, by subtracting a range offset and repacking the two bytes as high × 0xC0 + low. Its mode indicator is 1000.

Is kanji mode smaller than UTF-8 for Japanese text?

Yes — 13 bits per character against 24 bits for UTF-8's three bytes, a 46% saving that can reduce the QR version for text-heavy payloads. The saving vanishes for mixed content, where mode-switching headers eat into it.

Why do most generators not use kanji mode?

Because UTF-8 in byte mode works on every modern scanner while Shift-JIS handling is a legacy burden for whatever consumes the decoded text. Many libraries, UseQR's included, simply never emit kanji mode.

Can all scanners read kanji mode?

Phone cameras and mainstream libraries can. Some minimal or non-Japanese embedded decoders cannot, or return raw Shift-JIS bytes the receiving software then mishandles. If you ship kanji mode, test the exact readers your audience will use.