A QR mode indicator (0111) followed by a designator number that tells the scanner which character encoding the bytes use — most commonly 000026 for UTF-8.
QR code byte mode stores raw 8-bit values, but bytes are meaningless without a character encoding: the same byte is 'é' in Latin-1, part of a multi-byte sequence in UTF-8, and something else entirely in Shift JIS. ECI (Extended Channel Interpretation) mode is the mechanism that resolves this ambiguity. The encoder inserts the ECI mode indicator (0111) followed by a variable-length designator number, and every byte after it is interpreted in the named encoding until another ECI designator or the end of the symbol.
The designator numbers that matter
ECI designators are registered values. The ones you will actually encounter: 3 for ISO-8859-1 (Latin-1, the default interpretation when no ECI is present), 26 for UTF-8 (the modern universal choice), and 20 for Shift JIS. The designator uses a variable-length encoding of its own — small values take one byte, larger values take more — so the common cases cost almost nothing. A QR code carrying Urdu, Arabic, Chinese, or emoji text is, under the hood, byte mode plus ECI 000026 plus UTF-8 bytes.
Why the default is not UTF-8
The specification predates UTF-8's total victory: byte mode's default interpretation is ISO-8859-1. In practice, most modern phone decoders assume UTF-8 for byte-mode data even without an ECI header — which is why unmarked UTF-8 QR codes usually "just work." But "usually" is doing heavy lifting there. Enterprise scanners, industrial readers, and strict decoders follow the specification: without ECI 26, bytes above 127 are Latin-1, and your Urdu or Chinese text arrives as mojibake. Explicit ECI is the difference between working by accident and working by contract.
Encoder and decoder responsibilities
A correct encoder adds the ECI designator automatically when you select UTF-8 output — you should never hand-craft these bits. The designator applies from its position forward, so mixed-encoding symbols are possible (Latin-1 segment, then an ECI switch to UTF-8), though rarely needed. On the decode side, applications must honor the designator: a surprising number of hand-rolled QR parsers ignore ECI and hard-code UTF-8, which works until someone scans a legitimate Latin-1 or Shift JIS symbol. If you write decoder-side code, handle ECI properly; if you buy scanning software, verify it does.
Testing multilingual codes
Generate the code, scan it with at least two independent apps (one iOS, one Android), and check every non-ASCII character individually — mojibake often corrupts only some characters, and a quick glance can miss it. Pay special attention to combining characters and right-to-left scripts, where rendering issues can masquerade as encoding issues. For vCard and MeCard payloads with non-Latin names, the same ECI 26 mechanism applies inside the contact format.
Diagram description: Bit-stream diagram: ECI mode indicator 0111, designator 000026, then UTF-8 bytes of a non-Latin word, with a comparison showing the same bytes misrendered as Latin-1 without the ECI header.