Garbled subtitle characters, explained and fixed

You open a subtitle file and the dialogue is readable, until a name or an accented word turns into nonsense. café becomes café, niño becomes niño, and quotation marks become “. The file is not corrupted, and you have not done anything wrong. What you are looking at is mojibake, the classic symptom of a character-encoding mismatch. This guide explains what is actually happening and how to get the real text back.

What character encoding actually is

Computers store text as numbers. An encoding is the agreed lookup table that says which number means which character. For plain English letters, almost every encoding agrees, so the letter A is 65 everywhere. The disagreements start with everything else. Accented letters, curly quotes, dashes, currency symbols and non-Latin scripts all land in the contested territory.

Two encodings matter for subtitles.

• UTF-8 is the modern, universal standard. It can represent every character in every language, and it is what virtually all software expects today.
• Windows-1252 (and the related ISO-8859-1, also called Latin-1) is an older single-byte encoding common on Western Windows systems. It covers Western European accents but nothing else.

Mojibake happens when a file is written in one encoding and read in another. The bytes are fine. They are simply being interpreted with the wrong lookup table.

Why “café” becomes “café”

Here is the mechanism, because understanding it makes the fix obvious. In UTF-8, an accented é is stored as two bytes. When a program that assumes Windows-1252 reads those two bytes, it does not see one é. It sees two separate single-byte characters, which happen to be Ã and ©. So café is displayed as café.

This is why mojibake has such recognisable patterns. é is almost always a misread é, ñ is ñ, and “ and â€ are curly quotation marks. Once you spot those tell-tale Ã and â€ sequences, you know exactly what went wrong. UTF-8 text is being read as Windows-1252, or the reverse.

The good news is that the data is not lost

The most important thing to understand is that the original text is still recoverable. Mojibake is a display problem, not data loss. The bytes that spell out the correct word are sitting right there in the file. They are just being decoded with the wrong table. Fix the table, and the real text reappears intact.

This is different from a genuinely corrupted file, where bytes are missing or scrambled. With mojibake, nothing is missing, so nothing needs to be guessed or reconstructed.

How to fix it properly

The reliable fix has three steps.

1. Detect the file’s real encoding. A good encoding detector reads the raw bytes and works out, with high confidence, which encoding actually produced them, whether that is Windows-1252, ISO-8859-1, UTF-8 or something else.
2. Re-decode the bytes with the correct encoding. This is the step that turns café back into café.
3. Re-save the file as UTF-8. Writing the result as clean UTF-8 means every modern player and editor will read it correctly from now on, so the problem does not come back.

The SubAlign encoding repair tool does all three in your browser. It inspects the bytes of your subtitle file, identifies the source encoding, re-decodes the text correctly, and gives you a clean UTF-8 file to download, without ever uploading your file to a server.

What about the byte-order mark (BOM)?

You may sometimes see a stray character, often shown as “, right at the very start of a file, before the first subtitle. That is usually a UTF-8 byte-order mark, an invisible marker some editors add. Most players cope with it, but a few choke on it, which can make the first subtitle fail to display. Re-saving the file cleanly removes a problematic BOM along the way.

Why this happens to subtitles so often

Subtitles are passed around the world more than almost any other kind of text file. A file created on a Western Windows machine in Windows-1252, downloaded and opened on a Mac or a Linux media server that assumes UTF-8, is a perfect recipe for mojibake. Languages full of accents, like French, Spanish, Portuguese and the Nordic languages, suffer the most. It is not a sign anyone made a mistake. It is just the seams between old and new encoding standards showing through.

Will fixing it damage a file that is already fine?

A careful repair tool checks first. If the file is already valid UTF-8 with no encoding problems, the right behaviour is to tell you so and leave it untouched, rather than re-processing it and risking a change. You should only ever re-decode a file that genuinely needs it.

The bottom line

Garbled subtitle characters look alarming but are one of the most fixable problems there is. Mojibake is an encoding mismatch, not corruption. The correct text is still in the file, waiting to be read with the right lookup table. Detect the true encoding, re-decode to UTF-8, and save. café becomes café again, for good.