Charset Converter — Fix Mojibake
Fix mojibake by decoding legacy code pages — Windows-1252, ISO-8859, Shift_JIS, EUC-KR, GBK, Big5, KOI8-R and more — back to correct Unicode text.
Decoding uses the browser’s native TextDecoder, and works offline.
Turn garbled text back into readable characters
When a file or database was saved in a legacy code page — Windows-1252, ISO-8859, Shift_JIS, EUC-KR, EUC-JP, GBK, GB18030, Big5 or KOI8-R — but later read as UTF-8 (or the wrong code page), you get mojibake: café turns into café, and Korean shows up as ÇѱÛ. Paste the raw bytes as hex or Base64, or drop the file, choose the charset the bytes were originally written in, and read the correct Unicode text instantly. Not sure which it was? The page makes a best guess from the bytes, with a Use it button when the guess differs from the charset picked, and Every charset side by side shows what each charset makes of them at once, best first, marked ✓ where every byte was valid. The Encode text tab goes the other way: it writes Unicode text in a legacy charset, shows the bytes as hex and saves them as a file — for every charset in the list but GB18030. Text that was garbled more than once can go round again: "Fix this result again" puts the result back in the "Paste garbled text" box and looks for another layer.
How it works
Everything runs on the browser-native TextDecoder, which implements the WHATWG Encoding Standard — the same decoder your browser uses to render web pages. There is no library and no server round-trip, and it works offline, so your bytes never leave your device.
Frequently asked questions
What is mojibake?
Mojibake is garbled text that appears when bytes encoded in one character set are decoded as another — for example, legacy Windows-1252 or EUC-KR bytes read as UTF-8. Choosing the correct source charset here restores the original characters.
Which encodings are supported?
Every code page the browser TextDecoder supports, including Windows-1250 to 1258, ISO-8859-2/5/6/7/8/13/15, KOI8-R and KOI8-U, Mac Roman, Shift_JIS, EUC-JP, EUC-KR, GBK, GB18030 and Big5. UTF-8 is included too so you can verify already-correct bytes, and UTF-16 LE and BE follow it. Encode text can write every one of them except GB18030, whose four-byte half the browser gives no table for.
How do I get the bytes of my text?
Paste them as hex (like 48 65 6c 6c 6f) or Base64, or switch to Upload file and drop the file directly — the tool reads its raw bytes and decodes them with the charset you pick.
Can it work out the charset for me, or write text into an old charset?
Both. In the hex and file tabs, Best guess from the bytes names the most likely charset — weighing UTF-8 validity and a BOM, text in a single coherent script, Hangul or kana that only the right reading produces, and words a wrong reading gives away — with a Use it button when it differs from the one picked; what bytes alone cannot settle, such as EUC-KR against GBK, is settled by the page’s language and your browser’s. Every charset side by side shows every charset’s reading at once. The Encode text tab writes text in a chosen charset, and its download saves those bytes, not UTF-8; a character the charset has no bytes for is refused by name and position.
Does it handle UTF-16, or text that was garbled twice?
Both. UTF-16 LE and BE are listed right after UTF-8, and the best guess offers them only when the bytes carry a byte-order mark or a zero in every other byte, since plain ASCII also decodes cleanly as UTF-16. For text garbled more than once, "Fix this result again" beside Copy puts the result back in the garbled-text box and repairs it again.