Character Encoding: ASCII, UTF-8 and QR Codes

Character encoding is the invisible agreement that turns the letters you type into the numbers a computer stores — and when a QR code and a scanner disagree about which agreement they're using, that's exactly when your accented letters and emojis turn into garbled nonsense.

Ever scanned a QR code and seen café come out as café? Or an emoji become a row of question marks? You've bumped into a character-encoding mismatch. It's one of the most common quiet gremlins in the QR world, and once you understand ASCII, Latin-1, UTF-8, and a mechanism called ECI, it all makes sense. Let's untangle it. 🐾

Why text has to become numbers

Computers only store numbers. A QR code, at heart, holds a stream of bits — ones and zeros — which group into bytes (numbers from 0 to 255). To store the letter "A," we first agree that "A" equals a particular number, then store that number. Character encoding is that agreement: a lookup table mapping characters to numbers and back. Our companion piece on how computers represent text covers the fundamentals; here we focus on what it means for QR.

ASCII: the original 128

ASCII is the granddaddy of encodings. It defines 128 characters — the uppercase and lowercase English letters, the digits, common punctuation, and a space — each mapped to a number from 0 to 127. "A" is 65, "a" is 97, "0" is 48, and so on. Seven bits are enough to cover all 128.

ASCII is simple and universal: every encoding that matters today agrees with ASCII for those first 128 characters. The catch is what it lacks — no accented letters, no "£" or "€", no non-English scripts, and certainly no emoji. For plain English, ASCII just works, and a QR code holding only ASCII characters is about as safe and portable as it gets.

Latin-1: filling the second half

Bytes can hold values from 0 to 255, so there's room for another 128 characters beyond ASCII. Latin-1 (formally ISO-8859-1) uses that upper range to add many Western European characters: "é," "ñ," "ü," "ç," "£," and friends. Values 0–127 stay identical to ASCII; values 128–255 carry the extras.

Latin-1 matters for QR codes because it's the default assumption many scanners make when reading byte mode. If a code's bytes were written as Latin-1 and read as Latin-1, accented Western European text comes through perfectly. Problems start when one side assumes Latin-1 and the other assumes something else.

UTF-8: one encoding to rule them all

UTF-8 is the modern universal encoding, and it's what most of the web uses. It can represent every character in Unicode — every script, symbol, and emoji on Earth — by using a variable number of bytes per character:

• The 128 ASCII characters still use a single byte (and are byte-for-byte identical to ASCII).
• Accented and many common characters use two bytes.
• Less common characters use three bytes.
• Emoji and rarer symbols use four bytes.

This backward compatibility with ASCII is genius: plain English text is identical in ASCII and UTF-8. But an "é" in UTF-8 is two bytes, whereas in Latin-1 it's one. That single difference is the root of most QR garbling.

The letter "é" is one byte in Latin-1 but two bytes in UTF-8. If a code is written one way and read the other, the mismatch shows up as gibberish like "é".

Where QR codes fit in

QR codes have four encoding modes, and text usually travels in byte mode (8 bits per character). Byte mode stores raw byte values but doesn't inherently say which character set those bytes represent. Our QR code encoding modes guide covers all four modes; the crucial point here is that byte mode is where the encoding question arises.

So when a generator encodes "café" and a scanner decodes it, both have to agree on the character set. If they don't, you get mojibake — the technical (and rather charming) name for garbled decoded text.

ECI: declaring the character set

The QR standard has a proper solution: ECI, or Extended Channel Interpretation. ECI is a little marker the encoder can place in the data to say, in effect, "the bytes that follow use character set number X" — for example, UTF-8. A scanner that understands ECI reads the marker and interprets the bytes correctly, so "é" and emoji come through as intended.

The wrinkle is that not every scanner or generator handles ECI perfectly. When ECI is missing, a reader has to guess. Some assume Latin-1; some try to auto-detect UTF-8; results vary by app and phone. That inconsistency is why the same code can look fine on one phone and garbled on another.

Why emojis and accents sometimes garble

Now the mystery solves itself. Garbling happens when the encoding used to write the code and the encoding used to read it don't match. Common scenarios:

• UTF-8 written, Latin-1 read. The two bytes of a UTF-8 "é" get read as two separate Latin-1 characters, producing "é."
• No ECI marker. The scanner guesses the character set and guesses wrong.
• Emoji everywhere. Emoji only exist in Unicode and need UTF-8; a scanner assuming Latin-1 can't represent them and shows question marks or boxes.
• Old scanners. Some older readers don't support ECI or UTF-8 well, so anything beyond ASCII is a gamble.

Encoding	Covers	Bytes per char	Notes
ASCII	English letters, digits, basic punctuation	1 (values 0–127)	Universally safe
Latin-1	ASCII + Western European accents	1 (values 0–255)	Common QR default
UTF-8	Every Unicode character + emoji	1 to 4	Web standard; needs ECI in QR for reliability

How to avoid garbled QR codes

A few friendly habits keep your codes clean:

1. Stick to plain ASCII when you can. Basic English letters, digits, and simple punctuation decode identically everywhere. This is the single most reliable choice.
2. Use a generator that adds ECI for UTF-8. If you need accents or non-Latin text, make sure the tool signals UTF-8 via ECI so compliant scanners interpret it correctly.
3. Test on multiple phones. Scan your finished code with a couple of different devices before printing thousands of copies.
4. Go easy on emoji. They're the most fragile content across scanners. Lovely when they work, risky when they don't.
5. Percent-encode tricky characters in URLs. For links, using standard URL encoding for special characters sidesteps many issues entirely.

The bigger picture

Character encoding is one of those foundational ideas that touches everything digital, not just QR codes. If you'd like the ground-up version, our guides to how computers represent text and the QR encoding modes pair nicely with this one. And for the anatomy of where these bytes actually live inside the square, see the anatomy of a QR code.

When you make a code with QR Puppy, you don't have to sweat the encoding — but knowing what's happening under the hood helps you spot trouble early. Ready to try one? You can create a free QR code, static and standard, in seconds.

Frequently asked questions

Why does my accented text turn into weird symbols?

Because the code was written in one encoding (often UTF-8) and read in another (often Latin-1). A UTF-8 "é" is two bytes, which a Latin-1 reader shows as two odd characters like "é." Using ECI to declare UTF-8, or sticking to plain ASCII, avoids it.

Can a QR code hold emoji?

Yes, but carefully. Emoji require UTF-8, and the code should signal that with ECI. Even then, some scanners don't render emoji well, so they're the least reliable content. Test widely before relying on them.

What is ECI in plain terms?

ECI (Extended Channel Interpretation) is a small marker inside the QR code that tells the scanner which character set the bytes use, such as UTF-8. It helps non-English characters decode correctly instead of garbling — provided the scanner supports ECI.

Is ASCII text always safe in a QR code?

Effectively, yes. The 128 ASCII characters (English letters, digits, basic punctuation) map to the same byte values in ASCII, Latin-1, and UTF-8, so they decode identically on virtually any scanner. It's the safest content you can use.

Does the encoding affect how big my QR code is?

It can. UTF-8 uses more bytes for accented characters and emoji (two to four each) than ASCII or Latin-1, so text with lots of special characters produces a larger, denser code. See our data capacity guide for how length affects size.