.SRT.VTT.SBV.ASS.SSA

Subtitle Encoding & Mojibake Repair

Repair subtitle files that show é instead of é. Detects Windows-1252 and UTF-16 input, fixes double-encoded accents and punctuation, and removes a stray byte order mark. Runs entirely in your browser.

100% In-Browser · Zero Upload
Zero latency · Client-side Web Worker

Drop your subtitle file to check its encoding

Accents, punctuation and byte order marks are repaired locally

What Mojibake Actually Is

Subtitles that display café instead of café are not corrupted in a way that plays badly, they are corrupted in a way that was written down. An accent such as é is two bytes in UTF-8:0xC3 0xA9. When a tool reads those two bytes as Windows-1252, it sees two separate characters,à and ©. If that text is then saved again as UTF-8, the wrong characters become the real contents of the file. Re-opening it in a different player changes nothing, because there is no longer any encoding mistake to recover from: the file genuinely says é.

Damaged (double encoded)
Café scene, shot in Montréal.
Budget was €4,000 for the take.
Repaired
Café scene, shot in Montréal.
Budget was €4,000 for the take.

The Two Problems This Tool Separates

  • Wrong read, intact bytes. The file really is Windows-1252 or UTF-16 and was read as UTF-8. Nothing has to be guessed, it just has to be re-saved as UTF-8 so every player reads it the same way.
  • Damage already in the text. An earlier pipeline stored the wrong characters. Those sequences are converted back to bytes and read as UTF-8, which restores the original characters.
  • Hidden byte order mark. An invisible marker in front of the first cue number is a common reason a file opens with a broken first subtitle or a stray character.

Why the Repair Is Conservative

A repair that rewrites text aggressively is worse than the damage, because it silently changes dialogue. This one only touches a run of characters that can all be mapped to single Windows-1252 bytes and that decode as valid UTF-8 once they are put back. Everything else, including correctly encoded accents and entire non-Latin scripts, is left byte for byte as it was, and the results panel shows you each before-and-after pair before you download anything.

Frequently Asked Questions

Why does my subtitle file show characters like é instead of é?
The text was encoded as Windows-1252 bytes and then read as if those bytes were UTF-8. The wrong characters are now stored in the file itself, so opening it in another player will not help. Repairing it means turning the characters back into their original bytes and reading those as UTF-8, which is what this tool does.
Will this tool break correctly encoded accents?
No. Repair is only applied to a run of characters that can all be mapped back to single Windows-1252 bytes and that then decode as valid UTF-8. A correct é on its own is not a valid byte sequence, so it is left untouched, and so is text in Japanese, Cyrillic, Arabic or any script outside Windows-1252.
What is the difference between a wrong encoding and mojibake?
A wrong encoding means the bytes are fine but were read with the wrong rules, so the file is intact and only needs to be re-saved as UTF-8. Mojibake means the damage was already written into the text by an earlier tool, so the characters themselves have to be repaired. This tool reports which of the two you have and fixes both.
Why does my first subtitle disappear or show a strange character?
A hidden UTF-8 byte order mark is sitting in front of the first cue number. Some players and editors treat it as part of the number and drop the cue. The byte order mark is detected and removed here, including the damaged form that appears as three nonsense characters at the start of a file.
Are my subtitles uploaded anywhere?
No. The file is read in your browser and repaired there. There is no upload, no account, and nothing to clean up afterwards, which is the same promise every tool on this site keeps.