UTF-8 vs the Old Encodings

Nearly every case of garbled text comes down to one of these being confused for another. This page assumes you have never thought about encodings before.

Computers store numbers, not letters

There are no letters inside a computer. Only numbers. So to store the letter é, the machine consults a table that says "é is number so-and-so" and writes that number down. To read it back, it consults the same table in reverse.

The whole problem is that there is more than one table. Write with one table, read with another, and the same numbers come back as different characters. That is all mojibake is. Nothing was lost — the numbers were simply looked up in the wrong book.

The old tables were regional

Before the web, each region built its own table. Western Europe had Latin-1 and its Windows cousin CP1252. Russia had KOI8-R and CP1251. Korea had EUC-KR, Japan Shift_JIS, China GBK.

Each one held the local alphabet and not much else. That kept files small, which mattered when storage was expensive. The cost was that you could not put Russian and Japanese in the same document — neither table had numbers for the other's characters.

Worse, the single-byte tables all covered the same numeric range. A file written in CP1251 and a file written in Latin-1 look identical to a program: just bytes from 0 to 255. Nothing in the file says which table was meant. The program has to guess, and it often guesses wrong.

UTF-8 — one table for everything

Unicode was the agreement to stop having regional tables and give every character in every writing system its own number. UTF-8 is the most common way of writing those numbers into a file, and it now covers more than 98% of the web.

It holds Latin, Greek, Cyrillic, Arabic, Hebrew, Hangul, kana, Han characters, and emoji. You can mix them freely in one document. English letters take one byte each and keep the same numbers they always had, which is why UTF-8 slid into existing systems so easily. Accented Latin takes two bytes, most Asian characters three.

Why English speakers see this less

Plain English is the one thing that survives almost any mismatch, because A–Z have the same numbers in every table. Pick the wrong table and the English still reads fine.

Everything else breaks. é has one number in Latin-1 and a different two-byte sequence in UTF-8, so the moment the tables disagree the text falls apart — and because the byte counts differ, the character count changes too.

The two classic shapes look like this.

été — French written as UTF-8, read as CP1252. Each two-byte character split into two Western letters.
안녕하세요 — Korean written as UTF-8, read as CP1252. Three bytes each, so the text swells further.

In both cases the original numbers are still sitting in the file. Choose the right table and the text comes straight back — which is exactly what Mojibake Recovery does.

What to use now

UTF-8, without thinking about it. New files, web pages, databases, APIs — all UTF-8. The old encodings are only needed for reading files that already exist.

If you still have legacy files around, converting them is worth doing. Modern tools assume UTF-8 by default, so those files are one careless open away from being garbled. Upload them on the File tab and the encoding is identified and converted for you.

One stubborn exception is Excel, which still reads unmarked UTF-8 files using the local Windows code page. That case has its own page: CSV garbled in Excel.