Fix Garbled Subtitles: UTF-8, ANSI and Text Encoding Problems Explained

You load a subtitle file and, instead of "café" or "señor", you see "café" and "señor". Or an Arabic, Russian, or Greek subtitle turns into a row of question marks and boxes. The words are all in the file, yet the screen shows nonsense. This is one of the most common subtitle problems, and it has nothing to do with the translation itself. It is a text encoding problem, and it can almost always be fixed in under a minute once you know what is happening.

This guide explains what encoding is, why subtitles are so often affected, how to tell which encoding a file uses, and how to convert it to UTF-8, the format that works everywhere. It also covers the old ANSI code pages behind most of the damage.

What is text encoding?

A computer stores text as numbers. An encoding is the agreed table that says which number stands for which character. If the program that saves a file and the program that reads it use the same table, the text appears correctly. If they use different tables, the same numbers produce different characters, and you get what looks like garbage.

In the early days, each region had its own table. Western European languages used one, Cyrillic another, Greek another, Arabic another, and so on, and none of them could mix languages in one file. Then came Unicode, a single catalogue containing characters from essentially every writing system, and UTF-8, the most common way of storing Unicode as bytes. UTF-8 is now the default on the web, on modern operating systems, and in nearly all current software.

Why subtitles are so often affected

Subtitles have been shared on the internet since long before UTF-8 became the norm. Many files in circulation were saved in a regional encoding, and they have been copied, uploaded, and downloaded ever since. When you open one in software that assumes UTF-8, as many current programs do, the bytes are read with the wrong table.

The tool you use to open the file matters too. A player may guess the encoding and sometimes guess wrong. Some programs let you choose it. Some, like the browser-based subtitle merger, read files as UTF-8, because that is what a browser does by default. That is a good reason to convert old files before loading them.

Recognising the symptoms

The kind of garbage you see is a clue to the cause.

"é", "ñ", "ü" and similar pairs of odd characters. The file is UTF-8, but the program is reading it as a single-byte Western encoding such as Windows-1252. Fix: tell the program to read it as UTF-8.

Question marks or black diamonds in place of accented letters. The file is probably in a single-byte encoding such as Windows-1252, and the program is reading it as UTF-8. The bytes do not form valid UTF-8 sequences, so the reader substitutes a replacement symbol. Fix: convert the file from its real encoding to UTF-8.

Rows of question marks for an entire non-Latin script. The original text may have been lost when the file was saved. If a program saved Arabic or Chinese text in an encoding that has no such letters, it replaces them with question marks permanently. Once real question marks are stored in the file, the lost characters cannot be recovered from that file, and you need another copy.

Unreadable but different symbols, such as Cyrillic letters turning into accented Latin ones. The file uses a regional encoding such as Windows-1251 for Russian, and the program is reading it with another one. The fix is to identify the right encoding and convert.

A strange character at the very start of the first line. This is usually a byte order mark. Some Windows programs add three invisible bytes to the front of UTF-8 files. Good tools ignore them. A few strict ones display them as "" at the beginning. The SRT Merger removes this marker when it reads a file.

Common encodings you will meet

Encoding	Typical use
UTF-8	Modern default for every language
Windows-1252	Western European languages, such as English, French, Spanish, German
ISO-8859-1	Older Western European standard, very similar to Windows-1252
Windows-1250	Central European languages, such as Polish, Czech, Hungarian
Windows-1251	Cyrillic languages, such as Russian, Ukrainian, Bulgarian
Windows-1253	Greek
Windows-1254	Turkish
Windows-1256	Arabic
Windows-1255	Hebrew
GBK, Big5	Chinese
Shift-JIS	Japanese
EUC-KR	Korean

Knowing the language of the subtitles narrows the search enormously. A Russian file that looks wrong is almost certainly Windows-1251 or the older KOI8-R. A Polish file is likely Windows-1250 or ISO-8859-2.

How to find out what encoding a file uses

There is no marker inside most subtitle files that states their encoding, so identification is partly detective work. These approaches usually succeed.

Try the likely candidates. Open the file in a text editor that lets you reopen it with a chosen encoding. Many do, including Notepad++, which has an Encoding menu, and Visual Studio Code, which lets you reopen with encoding from the status bar. Try the encodings for the language and see which one makes the text readable. When the text is right, you have found it.

Use a subtitle editor. Programs like Subtitle Edit automatically detect and offer encodings when you open a file, and let you choose a different one if the guess is wrong.

Use a detection tool. On Linux and macOS, the file command and utilities like uchardet give a best guess. These tools work from statistical patterns, so they are less certain on short files, but subtitles tend to be long enough to give a good answer.

Look at the pattern of the damage. The symptoms listed earlier tell you whether you are dealing with UTF-8 read wrongly or a legacy encoding read as UTF-8.

How to convert to UTF-8

Once you have identified the source encoding, the conversion is quick.

In a text editor

1. Open the file using the correct source encoding, so that the text looks right on screen.
2. Use the editor's Save with encoding or Convert to UTF-8 command.
3. Save the file under a new name, keeping the .srt extension.

In Notepad++, for example, you open the file, choose the source encoding, and then use "Convert to UTF-8". Remember that the first step must make the text readable. If you convert while the text still looks wrong, you will simply save the wrong characters in UTF-8.

In a subtitle editor

Open the file, selecting the correct encoding if prompted, and save it as UTF-8 from the save options. Because the editor understands subtitles, it keeps timecodes and structure intact.

On the command line

The iconv command is available on Linux and macOS and in many Windows environments:

iconv -f WINDOWS-1251 -t UTF-8 input.srt > output.srt

Replace WINDOWS-1251 with the encoding you identified. If iconv reports an illegal sequence, the guess is wrong, or the file contains a few damaged bytes.

Byte order marks

For maximum compatibility, particularly with web tools, it is usually best to save UTF-8 files without the byte order mark. Some editors offer "UTF-8" and "UTF-8 with BOM" as separate choices. If a hardware player shows the marker as a stray character, resave without it. Some older Windows programs, on the other hand, need the marker to recognise a file as UTF-8, so if one of those refuses to read your file, try the other option.

Right-to-left languages

Arabic, Hebrew, Persian, and Urdu add another wrinkle. The characters are stored in logical order, and the player is responsible for displaying them right to left. If punctuation appears on the wrong side of a line, or a sentence seems reversed, the problem is usually the player's handling of text direction and not the encoding. Some files include invisible direction marks to help, so avoid stripping unfamiliar invisible characters from such files. If you merge or edit them, test in the player you will actually use.

Preventing encoding trouble

A few habits save a lot of headaches.

• Save everything as UTF-8. Make it your default in your editor.
• Convert downloaded files before editing them. A mixed-up encoding becomes harder to repair once you have saved over it.
• Keep an untouched original. If you convert the wrong way, you can start again.
• Do not copy subtitles through programs that replace characters. Some word processors and chat apps convert quotes and dashes into characters outside the file's encoding.
• Check after converting. Scroll through the file for characters special to the language, and play a few lines in your player.

Encoding and merging

When you combine two translations with the online SRT merger, both files should be UTF-8. If one is not, its accented characters will appear damaged in the comparison, and every line containing them will look different from its counterpart even when the words are the same. That can make a large share of rows look like conflicts. Convert first, then compare. Together with fixing sync problems, encoding is the second preparation step that makes the merge process go smoothly.

A quick troubleshooting flow

1. Does the text look right when you open it in your editor? If yes, there is no encoding problem.
2. If you see paired odd characters such as "é", reopen the file as UTF-8.
3. If you see question marks or diamonds in place of accents, the file is in a legacy encoding. Try the encodings for its language until the text is readable.
4. If the entire text is question marks that are really stored in the file, the original characters are gone and you need a different copy.
5. Save the readable version as UTF-8, without a byte order mark unless a program needs it.
6. Test it in your player.

Summary

Garbled subtitles are almost always an encoding mismatch and not a damaged file. UTF-8 is the encoding that works in every modern tool, so convert old files to it. Identify the original encoding by trying the likely candidates for the language, convert with a text editor, a subtitle editor, or iconv, and verify the result. Do it once, save the clean copy, and you will not meet the problem with that file again.