Byte mode
The QR encoding mode used for general text, at 8 bits per character.
QR codes have several encoding modes, and the generator picks the most efficient one that can represent the content:
- Numeric — digits only, about 3.3 bits per character
- Alphanumeric — digits, uppercase A–Z and nine symbols, 5.5 bits per character
- Byte — general text, 8 bits per character
- Kanji — Shift-JIS characters, 13 bits per character
The practical consequence. Alphanumeric mode cannot represent lowercase
letters. A URL written as HTTPS://EXAMPLE.COM/MENU encodes in alphanumeric
mode at 5.5 bits per character; the same URL in lowercase forces byte mode at 8 bits
— roughly 45% more data for identical content.
Should you uppercase your URLs? Domain names are case-insensitive, so the host portion can safely be uppercased. Paths usually are not, and a mangled path is far worse than a slightly denser code. It is a real optimisation for very constrained prints, and a bad default.
In practice
Encode HTTPS://EXAMPLE.COM/MENU — 24 characters, all alphanumeric-mode
characters — and you get a version 1 code at level M. Encode
https://example.com/menu and the lowercase letters force byte mode, giving
version 2.
Identical destination, one version apart, purely from letter case. Worth knowing, rarely worth acting on: uppercase URLs look shouty on a poster, and uppercasing a path that is actually case-sensitive produces a broken link, which is a far worse outcome than one extra version.
Questions
Does the generator choose the mode for me?
Yes. Any competent encoder analyses the content and selects the most efficient mode, including switching modes partway through a string.
Are URLs case-sensitive?
The scheme and domain are not. The path, query and fragment generally are — so
/Menu and /menu can be different pages on the same server.