Mojibake Fixer

What mojibake is and how this tool reverses it

Mojibake happens when text saved as UTF-8 is opened as a single-byte encoding, usually Windows-1252 or ISO-8859-1. A character such as é is stored as two bytes (C3 A9); read as Windows-1252 those bytes show as é. The damage is reversible because nothing was lost: the tool turns each suspicious character back into its byte, then reads the bytes as UTF-8 again. A sequence is only changed if the bytes form valid UTF-8, so text that is already correct (café, naïve, München, £5) is left alone.

The 0x80–0x9F range is where the two encodings differ. Windows-1252 puts printable characters there (€ ‚ ƒ „ … † ‡ ˆ ‰ Š ‹ Œ Ž ‘ ’ “ ” • – — ˜ ™ š › œ ž Ÿ), which is why a curly apostrophe (bytes E2 80 99) appears as ’, while ISO-8859-1 puts invisible control characters there. The tool handles both. Double encoding (the mistake made twice, giving things like ’) is undone one layer at a time, and each layer is listed above.

Limits. If a byte was lost (a � character, a missing character after â€, or question marks), the original cannot be worked out and the tool says so instead of guessing. Some characters in the wrong encoding can also look identical to correct text; always read the before-and-after list. Because the tool cannot know your intent, keep your original text until you have checked the result. For other conversions see the HTML entity encoder, URL encoder and Base64 tool.

Source / Last verified: Windows-1252 byte table (0x80–0x9F) from the WHATWG Encoding Standard, https://encoding.spec.whatwg.org/index-windows-1252.txt (the standard treats the ISO-8859-1 label as Windows-1252; the five undefined bytes 0x81, 0x8D, 0x8F, 0x90 and 0x9D map to the matching control characters). UTF-8 byte rules from RFC 3629 (shortest form only, no surrogates, maximum U+10FFFF). Last verified 26 September 2026 by comparing the table in this page with the downloaded WHATWG file.