How to Fix Garbled Subtitles: Encoding Problems With Accents and Special Characters
You open a Spanish, French or German subtitle file and instead of señor, café or Grüße you see señor, café and Grüße — or a row of question marks and little boxes. The subtitle is not damaged. What you are looking at is a text encoding mismatch: the file was saved using one system for turning letters into bytes, and the program reading it is using another. It is one of the most common subtitle problems, and it is usually fixed in under a minute once you know what to look for.
What text encoding is, in plain terms
A computer file is just a long sequence of numbers. A text encoding is the agreement about which number stands for which character. For plain English letters almost every encoding agrees, which is why English subtitles rarely break. For accented letters, non-Latin alphabets and symbols, different encodings assign different numbers, so the same bytes can mean different characters depending on the encoding the reader assumes.
Today the standard answer is UTF-8, an encoding that can represent every character in every language. Modern software, web browsers and subtitle tools expect UTF-8. Older files, and files made by older software or in some regions, are often saved in a legacy encoding such as Windows-1252, ISO-8859-1 or a language-specific code page. Opening one of those as UTF-8, or the reverse, is what produces garbled text.
Recognize the symptom
The kind of garbling tells you what went wrong, which saves guesswork:
| What you see | What happened | Fix |
|---|---|---|
| ó, é, ñ, ü in place of ó, é, ñ, ü | A UTF-8 file is being read as a legacy encoding such as Windows-1252 | Make the program read the file as UTF-8 — or if a tool already mangled it, start again from the original file. |
| Question marks or the replacement symbol � where letters should be | A file saved in a legacy encoding is being read as UTF-8, and the bytes do not form valid UTF-8 | Open the file using the legacy encoding it was saved in, then re-save it as UTF-8. |
| Unreadable Cyrillic, Greek, Arabic, Hebrew, Chinese, Japanese or Korean text | A language-specific legacy code page is being read as the wrong encoding | Identify the right code page for the language (see the table below), open with it, then save as UTF-8. |
| Empty rectangles or boxes, but the underlying text is fine | This is not an encoding problem: the font lacks the characters | Change the subtitle font to one that covers the language. |
Fix it with a text editor (no special software)
Windows Notepad
- 1Open the subtitle file in Notepad.
- 2If the text looks garbled, close it and re-open with File > Open, then choose the matching encoding in the Encoding box at the bottom of the open dialog.
- 3When the text looks right, choose File > Save As and set Encoding to UTF-8.
- 4Save with the same file name and extension (for example movie.srt).
Visual Studio Code (Windows, macOS, Linux)
- 1Open the file. The current encoding is shown in the status bar at the bottom right.
- 2Click it and choose Reopen with Encoding, then pick the encoding the file was really saved in (often Western European (Windows 1252) for Latin-script languages).
- 3Once the text looks correct, click the encoding again and choose Save with Encoding, then UTF-8.
macOS, Linux or Git Bash: the command line
iconv -f WINDOWS-1252 -t UTF-8 input.srt > output.srtReplace WINDOWS-1252 with whichever legacy encoding applies. The converted file will be written to output.srt and the original stays untouched, which makes this a safe way to experiment.
Which legacy encoding is it?
When a file comes from an unknown source, the language gives a strong hint about the legacy encoding it probably used. Try these candidates, and keep the one that makes the text readable:
| Language or region | Common legacy encodings |
|---|---|
| Spanish, French, German, Portuguese, Italian and other Western European languages | Windows-1252, ISO-8859-1, ISO-8859-15 |
| Polish, Czech, Hungarian and other Central European languages | Windows-1250, ISO-8859-2 |
| Russian, Ukrainian, Bulgarian and other Cyrillic languages | Windows-1251, KOI8-R |
| Greek | Windows-1253, ISO-8859-7 |
| Turkish | Windows-1254, ISO-8859-9 |
| Hebrew | Windows-1255 |
| Arabic | Windows-1256 |
| Japanese | Shift-JIS |
| Simplified Chinese | GBK, GB18030 |
| Korean | EUC-KR, CP949 |
A mixed or mangled result usually means you picked the wrong candidate. The correct encoding turns the whole file readable at once, not just part of it.
What about the BOM and line endings?
Two other invisible details come up in encoding discussions. The first is the byte order mark, or BOM, a few invisible bytes some programs put at the very start of a UTF-8 file. Most modern software ignores it, and it is harmless for the subtitle converters on this site, which strip it automatically, but a few older players and tools can trip over it. If a player rejects an otherwise valid file, saving as UTF-8 without BOM is worth trying.
The second is line endings. Windows files end lines with two characters (CRLF) while macOS and Linux use one (LF). Subtitle parsers generally handle both, and our converters normalize them, so this is rarely the cause of garbled text, but it can show up as odd blank lines in very old players.
Using this site's converters with non-English files
The converters on this site read your file as UTF-8, and write UTF-8 back out. That works directly for UTF-8 files in any language, including accented Latin text, right-to-left languages and emoji. If your file is in a legacy encoding, re-save it as UTF-8 first using one of the methods above, then run the conversion; otherwise the garbled characters will be carried straight into the output.
Everything still runs locally in your browser. Re-encoding does not involve uploading the file anywhere, whether you do it in Notepad, VS Code or on the command line.
A short troubleshooting routine
- 1Open the file in a plain text editor and look at the accented characters.
- 2If they look right in the editor but wrong in your player, the player is the problem: check its subtitle encoding setting or its font.
- 3If they look wrong in the editor, reopen the file with the legacy encoding that matches the language until the text looks right.
- 4Save as UTF-8, keeping the original file as a backup.
- 5Test in your video player or editor, and if you are delivering to a client, test in a second program as well.
Frequently asked questions
- Why does my subtitle look fine in a text editor but wrong in my video player?
- The text is stored correctly, but the player is guessing a different encoding or is using a font that lacks the characters. Look for a subtitle encoding or font option in the player's settings and set it to UTF-8 and a font that covers the language.
- Is UTF-8 always the right choice?
- For almost every modern use, yes. It supports all languages, it is the default for the web, and most subtitle tools and platforms expect it. Legacy encodings only make sense for very old software that cannot read UTF-8.
- Will converting between SRT and VTT fix encoding problems?
- No. Converting formats does not change how the characters were encoded. A garbled SRT becomes a garbled VTT. Fix the encoding first, then convert.
- Can I fix this without installing anything?
- Yes. Notepad on Windows and TextEdit on macOS can both open a file with a chosen encoding and save it as UTF-8, and the command line tool iconv is already present on macOS and Linux.