How to fix subtitle encoding problems (garbled characters)

You open a subtitle file and instead of "Voilà, c'est fini" you see "Voilà , c'est fini". Every accented letter has turned into a little cluster of nonsense, while the plain English words are untouched. This is one of the most common and most misunderstood subtitle problems, and the good news is that nothing is actually broken. The bytes in the file are perfectly correct — they are simply being read with the wrong decoder.

This post explains what is really happening at the byte level, how to figure out which encoding a file actually uses, and how to convert it to UTF-8 so the problem never comes back. Once you see why mojibake happens, the fix stops feeling like guesswork.

What is mojibake, exactly?

Mojibake — from the Japanese for "character transformation" — is text that has been decoded with a different character encoding than the one it was encoded with. An encoding is just a lookup table that maps numbers to letters. Save a file with one table and read it back with another, and every number that the two tables disagree on comes out as the wrong character. The information is intact; the interpretation is wrong.

It shows up on accented and non-Latin letters because those are exactly the characters the various tables disagree about. The basic Latin letters A-Z, digits and common punctuation sit at the same numbers in nearly every encoding, which is why "c'est fini" survives while "à" is mangled. If only the accents and special letters are broken, mojibake is almost certainly your problem.

Why does the wrong encoding garble text?

To see why, look at a single character. The letter "é" in the Windows-1252 encoding is stored as one byte with the value 233 (hex E9). UTF-8, the modern standard, stores "é" as two bytes: 195 and 169 (hex C3 A9). These are two different ways to write the same letter.

é  in Windows-1252  ->  1 byte:  E9
é  in UTF-8         ->  2 bytes:  C3 A9

When a UTF-8 reader meets the single byte E9 from a
1252 file, E9 is not a valid UTF-8 start on its own,
so it is shown as a replacement box or the wrong glyph.

The reverse case is the classic "é". A file is genuinely UTF-8, holding "é" as the two bytes C3 A9, but a program reads it as Windows-1252, which is a one-byte-per-character table. So it decodes C3 as "Ã" and A9 as "©" and prints both: "é". Two bytes meant as one letter get read as two letters. Every mojibake pattern is a version of this mismatch between how many bytes a character was written with and how many the reader expects.

Which encoding does my file use?

The hard part of the fix is that a plain text file does not usually announce its encoding — the same bytes could be several different languages. But the language of the subtitles is a strong clue, because legacy 8-bit encodings were regional. A Polish subtitle file from the Windows era is almost certainly Windows-1250; a Russian one, Windows-1251; a Japanese one, Shift-JIS.

You do not have to be certain in advance. A good fixer decodes the file with a candidate encoding and shows you the result, so you can confirm by eye that the accents came back correctly. If the first guess still looks wrong, try the next one for that language. The fix subtitle encoding tool automates this: it detects the probable encoding, re-decodes, and previews the readable text before you save.

How do you fix and save it correctly?

The fix is always the same three steps: identify the real encoding, re-decode the bytes with it, and save the result as UTF-8. That last step is what makes the fix permanent — UTF-8 can represent every language's characters in one universal table, so once a file is genuine UTF-8 there is no regional encoding left to guess wrong.

1. 1Identify the encoding from the language and the mojibake pattern, using the table above as a starting point.
2. 2Re-decode the file with that encoding so the accented characters are read correctly.
3. 3Save as UTF-8 (without a byte-order mark for the widest player support), which fixes the file for every program that opens it afterward.

How do you stop it happening again?

Once a file is saved as UTF-8, it stays readable everywhere, so the single best prevention is to convert every subtitle you touch to UTF-8 and never save in a legacy encoding again. When you edit a downloaded subtitle, check that your editor is set to write UTF-8 rather than the system default, which on some machines is still a regional 8-bit encoding.

After re-encoding, run the file through the subtitle preview tool to confirm every accent renders, and use the subtitle editor if any line still needs a manual touch. If the file is bound for a web page, convert it with SRT to VTT — which preserves the now-correct UTF-8 text — and if it carries leftover markup, remove subtitle formatting clears it. For any format change beyond that, the subtitle converter writes UTF-8 output by default. With clean text in hand you can safely add subtitles to a video knowing the accents will burn in correctly.

Frequently asked questions

Why are only the accented letters broken?

Because the basic Latin letters, digits and common punctuation sit at the same code numbers in almost every encoding, so they survive any mismatch. Only the accented and non-Latin characters differ between tables, which is why they are the ones that garble.

Is my subtitle file corrupted?

No. Mojibake is a display problem, not corruption. The original bytes are intact and the text is fully recoverable — it is just being decoded with the wrong encoding. Re-decode with the correct one and the words come back exactly.

What encoding should I save subtitles in?

UTF-8, ideally without a byte-order mark. It can represent every language in one table, so a UTF-8 subtitle displays correctly in modern players and browsers regardless of the viewer's system language, which ends the guessing for good.

Can I just find-and-replace the bad characters?

You could, but you should not. There are many mangled sequences, they are easy to miss, and manual edits can create new errors. Re-decoding the whole file with the correct encoding fixes every character at once by addressing the cause.