UTF-8 vs ASCII: Character Encoding Made Clear

By , Product Reviews Lead · Published 2026-07-20 · Last reviewed July 2026 · 8 min read · Editorial standards · Reviewed by Daniel Reeves
UTF-8 vs ASCII: Character Encoding Made Clear

Computers store text as numbers, and a character encoding is the agreed-upon table that says “65 means A.” For decades that table was ASCII. Today it is almost always UTF-8. Understanding the difference explains why you sometimes see “é” where an accented é should be, and how to stop it happening.

ASCII: elegant, but tiny

ASCII, from the 1960s, uses 7 bits to cover 128 characters: the English alphabet in both cases, digits, punctuation, and a few control codes. It is beautifully simple and still underpins everything — but 128 slots cannot hold accented letters, Greek, Cyrillic, Arabic, Chinese, or emoji. For an English-only world that was fine; for the actual world it was not nearly enough.

Unicode and UTF-8: room for everyone

Unicode is the giant catalogue that assigns a unique number (a code point) to every character in every writing system — over 149,000 of them, emoji included. UTF-8 is the clever way we store those numbers as bytes. Its masterstroke is backward compatibility: the first 128 code points are encoded identically to ASCII, so every old ASCII file is already valid UTF-8. Characters beyond that use two, three, or four bytes as needed, so common English text stays compact while the door stays open for every language.

Why you see garbled text (mojibake)

“Mojibake” — that soup of  and à symbols — happens when text is written in one encoding and read in another. A file saved as UTF-8 but opened as Windows-1252 (or vice versa) mangles every non-ASCII character. The single most common web cause is a page that omits the declaration. Fixing it is usually one line in the <head>: <meta charset="UTF-8">, plus making sure your database and server both speak UTF-8 end to end.

The practical rules

The guidance today is refreshingly simple: use UTF-8 everywhere. Save source files as UTF-8, declare charset=UTF-8 in HTML, set your database and connection to utf8mb4 (the full-emoji-capable variant in MySQL), and send the Content-Type: text/html; charset=utf-8 header. Do that consistently and the whole class of encoding bugs simply disappears. When you do hit garbled characters, the fix is almost always finding the one place in the chain that is not UTF-8.

Frequently asked questions

Is UTF-8 better than ASCII?

UTF-8 is a superset of ASCII — it can represent every character ASCII can, plus every other language and emoji. For anything beyond plain English, UTF-8 is essential.

Why does my text show weird symbols like é?

That is mojibake: the text was saved in one encoding and read in another. Declare UTF-8 consistently in your files, HTML, database and server to fix it.

What is the difference between Unicode and UTF-8?

Unicode is the catalogue that assigns a number to every character; UTF-8 is one way to store those numbers as bytes. UTF-8 is the most common Unicode encoding on the web.

Should I still care about ASCII?

ASCII still matters as the foundation UTF-8 is built on, but you should save and serve new content as UTF-8 to avoid encoding problems.