All guides

Fixing garbled characters in subtitle files

By Claudio Cárdenas · Updated 21 October 2026

In short: a subtitle file is a sequence of bytes, and the same bytes mean different letters depending on the encoding used to read them. Garbled accents almost always come from a file saved in one encoding and read in another — usually UTF-8 and Windows-1252. The fix is to read the file with the right encoding and save it again as UTF-8.

Why the same file can show different letters

Computers store text as numbers. An encoding is the table that says which number is which letter. For the basic English letters, digits and punctuation, nearly every encoding agrees. For everything else — accented letters, curly quotes, the euro sign, any non-Latin script — they disagree.

A subtitle file does not say which table it was written with. SRT and SBV have no place to declare it, and although WebVTT files are required to be UTF-8, many tools ignore that rule. The program opening the file has to guess, and when it guesses wrong, the text turns into what is known as mojibake.

The encodings you will meet

• UTF-8 — the modern standard, able to represent every script. Letters outside basic English take two to four bytes.
• Windows-1252 (and its close relative ISO-8859-1, also called Latin-1) — the default for Western European languages in older Windows software. Each letter is exactly one byte. Many subtitle files from the 2000s and early 2010s use it.
• UTF-16 — two bytes per basic letter. Some Windows tools still save “Unicode” text this way. It is usually marked with a byte order mark (BOM) at the start of the file, which makes it easy to recognize.

Recognizing the problem from the symptoms

The pattern of the damage tells you what happened:

The first two rows are the most common: a UTF-8 letter is two bytes, and a program reading the file one byte per letter shows each byte as its own character, which is why every accent becomes two symbols. The third row is the opposite mistake: a single Windows-1252 byte is not valid UTF-8 on its own, so the reader replaces it with the replacement character �.

How delsub reads a file

When you drop a subtitle file into delsub, it decides the encoding in this order:

1. If the file starts with a UTF-16 byte order mark, it is read as UTF-16.
2. Otherwise it is read as UTF-8, strictly: a single invalid byte makes that attempt fail.
3. If UTF-8 fails, the file is read as Windows-1252, which can decode any byte, and the status line says so.
4. If the Windows-1252 result contains the typical traces of misread UTF-8 (such as é or â€), delsub adds a warning that the characters look wrong and the file may be UTF-8 — usually a sign that the file mixes both encodings.

The status line always names the encoding that was used, for example “Loaded episode.srt (Windows-1252)”. If the accents in the output look right, nothing else needs to be done.

There is one case no program can repair by reading: when the damage is already saved in the file. If a file was converted the wrong way and then saved as UTF-8, it is perfectly valid UTF-8 that happens to contain the letters é. It is read correctly — it is the content that is wrong.

Converting a file to UTF-8

To fix a file for good, open it with the encoding it was really written in and save it as UTF-8:

• Visual Studio Code: click the encoding shown in the status bar, choose Reopen with Encoding and pick Western (Windows 1252). Once the text looks right, click the encoding again and choose Save with Encoding → UTF-8.
• Notepad on Windows: recent versions detect the encoding when opening. Use File → Save as and choose UTF-8 in the Encoding list at the bottom of the dialog.
• Command line: iconv -f WINDOWS-1252 -t UTF-8 input.srt > output.srt converts a file on macOS and Linux.

For text that was converted twice (the é case), the conversion has to be undone in reverse. Editors cannot do this reliably by hand; the Python library ftfy (“fixes text for you”) is designed for exactly this kind of repair.

Avoiding the problem

• Save subtitles as UTF-8, which every modern player, editor and website reads correctly.
• When a tool offers “UTF-8 with BOM”, either option is fine for subtitles; the BOM only helps older Windows programs recognize the file.
• Check a file before publishing it by searching for Ã or â€: in English and most Western languages, these sequences are almost always a sign of mojibake.

Four small files you can compare

Download the same synthetic caption in UTF-8, Windows-1252 and UTF-16 LE with a BOM. Load each into delsub with all switches on. The reported encodings differ, but all three produce this text:

Café mañana.

Now load the intentionally damaged UTF-8 file. Its bytes are valid UTF-8, so the decoder reports UTF-8 and the output stays:

Café mañana.

These four cases were reproduced using delsub’s decoder and cleanup functions on 21 October 2026. Compare the correct output, damaged output and recorded results. Each text export ends with a newline. Successful decoding does not establish that the letters are correct, and delsub does not automatically repair previously saved mojibake.

Sources and scope

Primary documentation checked on 21 October 2026. The examples above test delsub’s own behavior; they do not certify every subtitle file or third-party interface.

• WHATWG Encoding Standard — the TextDecoder API and legacy encoding labels.
• Visual Studio Code: file encoding support — reopening and saving a file with a selected encoding.
• W3C WebVTT specification — WebVTT’s required UTF-8 encoding.

Drop a subtitle file into delsub to see which encoding it uses: the status line names it, and the clean text can be downloaded as a UTF-8 .txt or .md file.