Fix broken characters
When accents turn into café, è or ’, the text is not broken: it was read with the wrong table. Here the chain is walked backwards, and healthy text is left untouched.
click to pick one (.txt, .csv, .srt, .vtt, .md, .json), it stays on your device
🔒 Your text and your files stay in your browser: nothing is uploaded to any server.
How to use it
Paste the mangled text into the box and press «Repair the text», or drop in a .txt, .csv, .srt, .vtt, .md or .json file. The tool tells you which encoding mistake was made, how many characters it recovered and shows a few before and after examples, so you can check the result really is what you expect before copying or downloading it.
Why «café» happens
In UTF-8 accented letters do not fit in a single byte: é is the pair C3 A9, à is C3 A0, the typographic apostrophe ’ is E2 80 99 and the non breaking space is C2 A0. When a program receives those bytes but believes they are written in Windows-1252 (the old «ANSI» table, where every byte is one letter) it shows them one at a time: C3 A9 becomes é, C2 A0 becomes  followed by a space, and E2 80 99 becomes ’. It is always the same fault, and it is why Italian, Spanish and French text falls apart almost sentence by sentence while English often gets away with it.
How this page repairs it
The chain is walked backwards: every character goes back to the byte it was according to the Windows-1252 table (including the 5 codes that table leaves undefined, which programs pass through unchanged), then those bytes are read again as UTF-8. Unlike a blind search and replace, healthy text is never touched: a lone é does not form a valid UTF-8 sequence, so it stays exactly as it is. When the fault happened twice in a row (the famous double encoding, the one with é) the round is repeated as long as needed, up to four times. There is also the Mac OS Roman table, for text coming from classic Macs, recognisable by its √© and ‚Äô. One last precaution is worth knowing: in an all caps heading, a Ù followed by a closing guillemet happens to form a valid UTF-8 pair by pure chance. That is why sequences starting with an ambiguous character are only repaired when the text holds at least three of them, and sequences that would turn into characters no real text contains (phonetic alphabet, Armenian) are left alone.
The opposite problem too, when the file itself is old
If you load a file, the tool looks at the real bytes first. A file that is not valid UTF-8 is read with the Windows-1252 table and handed back converted, and the same goes for the UTF-16 files that come out of Notepad and some business software. So both halves of the problem are covered: good text read the wrong way, and an old file that needs to become UTF-8. The download button adds, if you leave the box ticked, the BOM mark Excel needs to open a CSV without breaking the accents all over again.
What it cannot do, stated up front
Characters showing as � (or as invisible control symbols) cannot be recovered: that byte was already thrown away by whoever saved the file, and no program can guess it back. The same holds for accents that turned into a question mark. The tool knows the two common Western tables, Windows-1252 and Mac OS Roman, so it will not rebuild Cyrillic read as Windows-1251 or Japanese in Shift-JIS. It leaves HTML entities such as é or é alone, since those are a different problem, and it never changes the content: only the encoding is fixed. Everything runs in your browser, so the file is not uploaded anywhere.