ASCII, Unicode and UTF-8, Explained Simply

These three names get used interchangeably, and they are not the same thing. The difference matters the moment an accented name turns into mojibake like "José", or an emoji becomes a question mark in a database. Here is the plain-English version of what each one is, in the order they arrived.

ASCII: the original agreement

In the 1960s, computers needed a shared answer to "which number means which character". ASCII was that answer: a table of 128 numbers covering the English alphabet in both cases, the digits, punctuation, and some control codes. Capital A is 65, lowercase a is 97, a space is 32. Every character fits in a single byte with room to spare.

ASCII is why our binary translator can turn 01001000 into H: it is reading the byte as a number and looking it up in that table. The catch is what ASCII leaves out, which is nearly everything. No é, no ñ, no ¥, no Chinese, no Arabic, no emoji. Fine for 1963, useless for the actual world.

Unicode: one number for every character on Earth

Unicode is the modern successor, and the idea is simple even though the catalogue is enormous: give every character in every writing system its own permanent number, called a code point. Latin letters kept their old ASCII numbers, so A is still 65. Then the catalogue keeps going: é is 233, the yen sign is 165, the Greek letter π is 960, and the fire emoji is 128293. Well over a hundred thousand characters are catalogued, with more added every year.

The crucial thing to understand is that Unicode is only the numbering. It says "this character is number 128293" and stops there. It does not say how to store that number in bytes. That job belongs to an encoding.

UTF-8: how the numbers get stored

UTF-8 is the encoding that won. It stores small code points in one byte and larger ones in two, three or four bytes, using a prefix pattern that tells the computer how many bytes belong together.

Its winning move is backwards compatibility: every code point up to 127 is stored exactly the way ASCII stored it. A file of plain English text is byte-for-byte identical in ASCII and UTF-8, which is why the transition mostly just worked, and why UTF-8 now carries the overwhelming majority of the web. An é costs two bytes, most Asian characters three, and emoji four.

So why does text still break?

Mojibake, the José effect, happens when bytes written in one encoding are read as another. The é in José is code point 233, which UTF-8 stores as two bytes. Read those two bytes with an old one-byte-per-character assumption and you get two wrong characters instead of one right one: é. The bytes were never corrupted, they were just read with the wrong dictionary. When you see it, the fix is almost always telling the receiving program that the text is UTF-8.

Why this matters for the tools on this site

Several of our generators lean directly on the size of the Unicode catalogue. Small caps, superscript and the cursed text styles are not fonts or formatting, they are different Unicode characters that happen to look like styled versions of the alphabet, which is exactly why they survive copy and paste into places that strip formatting. Invisible characters are catalogued code points too. And the strikethrough generator uses combining characters, code points designed to stack onto the letter before them. Once you know text is just numbers in a very large catalogue, most "how is that possible in a bio?" mysteries stop being mysteries.

Frequently asked questions