Mojibake repair (garbled text fixer)
Repair text like café or don’t whose UTF-8 was read as Windows-1252, Latin-1 or MacRoman, including double encoding, with every candidate shown.
A clear answer. Here’s how.
Mojibake appears when the UTF-8 bytes of a text (RFC 3629) are decoded with a single-byte character set: é is the two bytes C3 A9, which Windows-1252 shows as é, and ’ is E2 80 99, shown as ’. For each of Windows-1252, ISO-8859-1 and MacRoman (tables from the WHATWG Encoding Standard and Unicode’s ROMAN.TXT, built in so every browser agrees) the page turns the characters back into those bytes and decodes again as UTF-8, replacing only runs that form valid UTF-8 so genuine characters are kept. It repeats up to three times for text encoded twice or three times (’ becomes ’ and then ’). Each candidate is scored by the suspicious sequences left (a character that would be a UTF-8 lead byte followed by one that would be a continuation byte, in any of the three character sets, plus C1 control and replacement characters) and by stray combining marks the repair added; the best is shown with all the others, and when two different repairs score the same the page says so rather than choosing. Bytes already lost, for example turned into ? or �, cannot be recovered by any tool, and damage from other character sets (Windows-1251, Shift JIS, GBK) or from mixing several of them is not repaired.
How this is checked
5 reference checks passed These 5 cases were run when this page was built, on 20 October 2026, and all reproduce within the stated tolerance. The same cases are part of the automated tests that run on every change to Toolmoz. Engine version 1.
See the checks and where each expected answer comes from
Case 1
- Inputs
- Garbled text café
- Expected, and what Toolmoz gave
- Best fix expected café, Toolmoz caféVerdict expected Looks right, Toolmoz Looks right
- Where the expected answer comes from
- By hand: é is U+00E9, UTF-8 C3 A9; Windows-1252 shows C3 as à and A9 as ©, so café was read as café
- Allowed difference
- exact
Case 2
- Inputs
- Garbled text don’t
- Expected, and what Toolmoz gave
- Best fix expected don’t, Toolmoz don’t
- Where the expected answer comes from
- By hand: ’ is U+2019, UTF-8 E2 80 99; Windows-1252 shows E2 as â, 80 as € and 99 as ™
- Allowed difference
- exact
Case 3
- Inputs
- Garbled text François
- Expected, and what Toolmoz gave
- Best fix expected François, Toolmoz François
- Where the expected answer comes from
- By hand: ç is U+00E7, UTF-8 C3 A7; Windows-1252 shows C3 as à and A7 as §
- Allowed difference
- exact
Case 4
- Inputs
- Garbled text привет
- Expected, and what Toolmoz gave
- Best fix expected привет, Toolmoz привет
- Where the expected answer comes from
- By hand: привет is UTF-8 D0 BF D1 80 D0 B8 D0 B2 D0 B5 D1 82; in Windows-1252 D0 is Ð, D1 Ñ, BF ¿, 80 €, B8 ¸, B2 ², B5 µ and 82 ‚
- Allowed difference
- exact
Case 5
- Inputs
- Garbled text ’
- Expected, and what Toolmoz gave
- Best fix expected ’, Toolmoz ’Passes expected 2, Toolmoz 2
- Where the expected answer comes from
- By hand: ’ (the Windows-1252 reading of ’) encoded again as UTF-8 is C3 A2 E2 82 AC E2 84 A2, which Windows-1252 shows as ’, so two passes are needed
- Allowed difference
- exact
What this shows: the engine reproduces independently worked values for these cases. It does not prove every possible input is right. To test an answer you were given, see how to check a number; to see what is and is not checked across Toolmoz, see the accuracy ledger.
See a worked example
Worked example
A fixed demonstration, separate from the values you enter above.
- Garbled text
- The café don’t serve crème brûlée.
Example result
| # | Read as | Passes | Result | Sequences repaired | Suspicious left | Looks right |
|---|---|---|---|---|---|---|
| 1 | Windows-1252 | 1 | The café don’t serve crème brûlée. | 5 | 0 | Yes |
| 2 | MacRoman | 1 | The caf̩ donâ۪t serve cr̬me brûl̩e. | 4 | 1 | No |
| 3 | ISO-8859-1 (Latin-1) | 1 | The café don’t serve crème brûlée. | 4 | 2 | No |
Each candidate turns the text back into bytes with one single-byte character set (Windows-1252, ISO-8859-1 or MacRoman, tables built in) and decodes the valid UTF-8 runs again, up to three times for double encoding. “Suspicious” counts pairs that look like a UTF-8 lead byte followed by a continuation byte, plus C1 control characters and replacement characters. When two repairs score the same the page says so instead of choosing.