Subtitle encoding problems
Subtitle files are plain text, which means their appearance depends entirely on how they were saved and how they are read. The same file can look perfect in one player and completely garbled in another. This article explains the common encoding problems and how to fix them.
The most common problem: wrong encoding
Subtitle files are supposed to be UTF-8. UTF-8 handles every character in every writing system, from ASCII to Chinese to emoji. If a file was saved as a different encoding (Latin-1, Windows-1252, Shift-JIS, etc.), accented characters and non-Latin scripts will display incorrectly.
What it looks like
- Non-ASCII characters appear as
?or�. - Accented letters look wrong:
ébecomesé. - Cyrillic, Greek or CJK text is entirely garbled.
Why it happens
Older subtitle tools, some Windows text editors, and files created in regions with non-UTF-8 default encodings may save with a different encoding. The bytes are valid but represent different characters when read as UTF-8.
How to fix it
Re-save the file as UTF-8. In most text editors:
- VS Code: click the encoding in the bottom-right → "Save with Encoding" → UTF-8.
- Sublime Text: File → Save with Encoding → UTF-8.
- Notepad (Windows): File → Save As → Encoding: UTF-8.
- TextEdit (macOS): Format → Make Plain Text, then save with UTF-8 in the dialog.
If the file was already corrupted (the original characters are lost), re-encoding will not fix it. You may need to re-download or re-create the file.
UTF-8 BOM: a subtle problem
The UTF-8 BOM (Byte Order Mark) is an invisible character at the very start of some files that tells readers the file is UTF-8. Most software ignores it. Some subtitle players do not — they fail to parse the first cue because of the unexpected character.
What it looks like
- A subtitle file that displays fine in a text editor but fails in the player.
- The player reports "invalid subtitle file" or shows nothing at all.
- Sometimes just the first cue is missing.
How to fix it
Use the Encoding Cleaner to strip the BOM. Or save the file without a BOM in your text editor (many editors let you choose "UTF-8 without BOM").
Zero-width characters
Zero-width characters are invisible but they exist in the file. They can come from copy-pasting from a PDF or website, or from text manipulation tools that insert them accidentally.
Common zero-width characters:
- U+200B — zero-width space
- U+200C — zero-width non-joiner
- U+200D — zero-width joiner
- U+FEFF — byte order mark (also appears at the start of some files)
- U+2060 — word joiner
What it looks like
- Subtitle text appears normal but strange things happen at the start or end of lines.
- Text alignment breaks in unexpected ways.
- Copy-pasting the subtitle text elsewhere produces strange artefacts.
How to fix it
Use the Encoding Cleaner. It strips all common zero-width characters.
Line ending problems
Windows uses \r\n (CRLF), Unix uses \n (LF) and classic Mac uses \r (CR). Modern players handle all three, but some older tools reject files with mixed line endings or with just CR.
What it looks like
- A file that looks correct in a text editor but has extra blank lines or missing line breaks in the player.
- Cue blocks that merge unexpectedly.
How to fix it
Use the Encoding Cleaner to normalize line endings to LF. Or in your text editor, convert line endings (usually an option in the File or Edit menu).
Non-breaking spaces
Non-breaking spaces (U+00A0) look identical to regular spaces but behave differently — they prevent word wrapping. In subtitle files, they can prevent lines from breaking where they should, leading to visual overflow or strange formatting.
How to fix it
Use the Encoding Cleaner to replace non-breaking spaces with regular spaces.
Prevention
- Always save as UTF-8, ideally UTF-8 without BOM.
- Use a plain text editor, not a word processor.
- Test the file in the player you will actually use before delivery.
- Validate the file with the SRT Validator or VTT Validator.
- When in doubt, run the file through the Encoding Cleaner before shipping.