# Kanji mode explained: 13 bits per character

> Kanji mode compresses double-byte Shift-JIS characters into 13 bits each by subtracting a range offset and repacking the two bytes. It is 46% denser than UTF-8 in byte mode for Japanese text, but most modern generators skip it and encode UTF-8 instead, which every phone scanner handles.

Source: https://useqr.app/docs/spec/kanji-mode-explained · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## Why a dedicated mode exists

QR codes were invented at [Denso Wave](/glossary/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](/docs/spec/data-encoding-modes) 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](/glossary/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](/glossary/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](/docs/spec/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](/docs/spec/qr-code-versions-1-to-40). 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](/validate).

## 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.

## Try it

- https://useqr.app/text
- https://useqr.app/url
- https://useqr.app/validate