QR code data encoding modes — numeric, alphanumeric, byte, kanji

The four modes

Every segment of a QR payload is stored in one of four encoding modes, each trading generality for density:

Mode	Indicator	Bits per character	Character set
Numeric	0001	3.33 (10 bits per 3 digits)	0–9
Alphanumeric	0010	5.5 (11 bits per 2 chars)	45 characters (below)
Byte	0100	8	any octets — in practice UTF-8
Kanji	1000	13	Shift-JIS double-byte characters

Numeric mode packs three digits into 10 bits (a leftover pair takes 7 bits, a single digit 4). Alphanumeric packs two characters into 11 bits as 45 × first + second, from this exact 45-character set:

0–9  A–Z  (space)  $ % * + - . / :

Uppercase only — there is no lowercase in the set. Byte mode is the fallback that takes anything, at a full 8 bits per byte. Kanji mode packs one double-byte Shift-JIS character into 13 bits.

The header every segment carries

A segment is: 4-bit mode indicator + character count + data. The count field's width depends on mode and version:

Mode	v1–9	v10–26	v27–40
Numeric	10	12	14
Alphanumeric	9	11	13
Byte	8	16	16
Kanji	8	10	12

Segments can be mixed in one symbol — a URL followed by a run of digits can switch to numeric mode mid-stream — but each switch costs a fresh mode indicator and count field (13+ bits), so switching only pays for runs longer than roughly a dozen characters. Encoders differ in how aggressively they optimise this, which is one reason two generators can produce different codes for the same text.

Why UPPERCASE URLs make smaller codes

https://useqr.app contains lowercase letters, so it must use byte mode — 8 bits per character. HTTPS://USEQR.APP fits the 45-character set and drops to 5.5 bits. Measured with UseQR's encoder at level M: the lowercase URL needs a version 2 (25 × 25) symbol; the uppercase one fits in version 1 (21 × 21).

The caveats that stop this being a free lunch:

• Scheme and host are case-insensitive, so HTTPS://USEQR.APP works everywhere.
• Paths and query strings are case-sensitive by standard. HTTPS://USEQR.APP/DOCS only works if the server treats /DOCS and /docs alike. Test before printing.
• The saving only matters when it crosses a version boundary, and only for dense codes near a size limit.

The same logic makes digits the cheapest payload of all: a numeric-only ID is 2.4× denser than the same characters in byte mode, which is why serial-number labels stay compact even with long identifiers.

What UseQR does

UseQR's encoder examines the payload and automatically selects numeric, alphanumeric or byte mode — the densest that fits, per the rules above. Kanji mode is not emitted (byte-mode UTF-8 carries Japanese text universally; see UTF-8 and Unicode in QR codes). You never choose a mode by hand — but knowing the rules lets you shape payloads so the good mode applies, then confirm the version you got.

FAQ

What are the QR code encoding modes?

Numeric (digits only, 3.33 bits per character), alphanumeric (a 45-character uppercase set, 5.5 bits), byte (any data, 8 bits), and kanji (Shift-JIS characters, 13 bits). The encoder picks the densest mode the payload's characters allow.

Why does an uppercase URL make a smaller QR code?

Alphanumeric mode's 45-character set has no lowercase letters. An all-uppercase URL qualifies for 5.5 bits per character instead of byte mode's 8, which can drop the symbol a full version — but URL paths are case-sensitive, so only uppercase the host freely.

Which characters are in QR alphanumeric mode?

The digits 0–9, uppercase A–Z, space, and the eight symbols $ % * + − . / : — 45 characters in total. One lowercase letter, comma, or underscore anywhere forces the whole segment into byte mode.

Can one QR code mix encoding modes?

Yes. The payload can be split into segments, each with its own mode indicator and character count. Switching costs 13 or more bits of header, so encoders only split when a run of digits or uppercase text is long enough to pay for it.