Subtitles Showing Weird Characters? How to Fix the Encoding

Subtitles show weird characters when the player reads the file in the wrong character encoding. Déjà instead of Déjà, þ instead of ş, diamonds, question marks: each pattern points to a specific cause. The fix is almost always the same: convert the file to UTF-8, or tell the player which old code page the file uses.

Below: how to read the garbled text, which code page your file is probably in, three ways to fix it on Windows and Mac, why boxes are a different problem, and how to stop it happening again.

Why do subtitles show weird characters?

An .srt file is plain text, and plain text does not say which encoding it was saved in. The player has to guess. It tries UTF-8, the encoding that holds every script, and when the bytes are not valid UTF-8 it falls back to a default, usually the old Windows code page of the computer it runs on.

Those old code pages are the root of the problem. Before UTF-8 was the norm, Windows stored text in one code page per region: Windows-1252 for Western Europe, 1254 for Turkish, 1251 for Cyrillic, 949 for Korean, 932 for Japanese. Each one reuses the same byte values for different letters. The byte that means ş in a Turkish file means þ in a Western one.

Microsoft's own code page reference states the problem plainly: these code pages "can be different on different computers, or can be changed for a single computer, leading to data corruption", and it recommends UTF-8 instead. A subtitle made on a Turkish or Korean PC years ago and played on an English laptop today is exactly that case.

The text itself is usually still in the file. Only the reading is wrong, which is why the fix is quick once you know the file's real code page.

What the garbled text tells you

Each symptom has its own cause. These samples come from real files we encoded and opened the wrong way:

The first two rows are the common ones, and they are opposites. In the first, the file is already correct and the player is wrong. In the second and third, the file is in an old code page, so it breaks in every player that does not guess that code page. Converting it once to UTF-8 fixes every player at the same time.

Which code page is your subtitle file in?

The language of the subtitles tells you. A file that is not UTF-8 is almost always in the old Windows code page for its language:

GB18030 is the superset of the Simplified Chinese code page, so it also reads files saved as GBK or GB2312.

To check what you have, open the file in Windows Notepad: the status bar names the encoding, and "ANSI" means an old code page. On a Mac, or in Git Bash on Windows, run:

file --mime-encoding subtitles.srt

utf-8 or us-ascii means the file is fine and the player is at fault. iso-8859-1 or unknown-8bit means an old code page. The tool cannot tell which one, so go by the language in the table.

Three ways to fix subtitle encoding

1. Re-save the file as UTF-8 in a text editor. Free and quick for one file.
2. Convert it with FFmpeg. One command, any code page, Windows, Mac and Linux.
3. Tell the player or encoder the encoding. No new file, but the fix stays in that one program.

The first two give you a UTF-8 file that plays correctly everywhere. The third is a workaround for one program on one computer.

Method 1: Save the subtitle file as UTF-8 in Notepad or TextEdit

On Windows, open the .srt in Notepad. When a file is not valid UTF-8, Notepad reads it in your Windows system code page. That works if the file matches your system: a Turkish file on a Turkish Windows opens correctly. If the text looks right, choose File → Save as, set Encoding to UTF-8, and save under a new name. If the text looks wrong in Notepad too, your system code page is not the file's, so use Method 2.

On a Mac, TextEdit lets you choose the encoding when you open the file. Apple's guide to characters that don't display correctly gives the steps: in the Open dialog, click Show Options, then choose an encoding from the Plain Text Encoding menu. Pick the one for the subtitle language, check that the text reads correctly, then save a copy as UTF-8. The default for saving lives in TextEdit → Settings → Open and Save, under Plain Text File Encoding.

Two limits: it is one file at a time, and it only works when the text looks right after opening. Never save a file that still looks garbled: you would write the wrong letters into UTF-8 for good.

Method 2: Convert subtitles to UTF-8 with FFmpeg

FFmpeg reads a subtitle file in any code page you name with -sub_charenc, which the FFmpeg documentation describes as "Set the input subtitles character encoding", and writes the output as UTF-8. Use the line for your language. We ran each of these on test files:

ffmpeg -sub_charenc CP1252 -i french.srt french-utf8.srt
ffmpeg -sub_charenc CP1250 -i polish.srt polish-utf8.srt
ffmpeg -sub_charenc CP1251 -i russian.srt russian-utf8.srt
ffmpeg -sub_charenc CP1253 -i greek.srt greek-utf8.srt
ffmpeg -sub_charenc CP1254 -i turkish.srt turkish-utf8.srt
ffmpeg -sub_charenc CP1256 -i arabic.srt arabic-utf8.srt
ffmpeg -sub_charenc CP932 -i japanese.srt japanese-utf8.srt
ffmpeg -sub_charenc CP949 -i korean.srt korean-utf8.srt
ffmpeg -sub_charenc GB18030 -i chinese.srt chinese-utf8.srt
ffmpeg -sub_charenc CP950 -i chinese-traditional.srt chinese-traditional-utf8.srt

-sub_charenc must come before -i. Leave it out and FFmpeg stops with this error, which is also how you can tell a file is not UTF-8:

Invalid UTF-8 in decoded subtitles text; maybe missing -sub_charenc option

If the output still shows wrong letters, the guess was wrong. Try the neighbouring code page from the table. A Cyrillic file read as CP1251 can never come out as Turkish, so a wrong guess is obvious at a glance.

The same command works on Windows, Mac and Linux, and FFmpeg is free.

Method 3: Set the encoding in VLC, HandBrake or the FFmpeg burn-in

When you would rather not make a new file, tell the program that reads it.

VLC. The VideoLAN wiki's subtitle encoding page gives the path: Tools → Preferences, then Subtitles / OSD → Default encoding. Pick the code page, press Save and restart VLC. This helps with the second and third rows of the symptom table. It changes VLC on that computer only: the same file still breaks on a TV, a phone or a media server.

HandBrake. When you import an SRT on the Subtitles tab, HandBrake's documentation says to "make sure the correct character code is selected from the 'Char Code' dropdown", and warns that the wrong one "will result in your output file having no subtitle track".

FFmpeg burn-in. The subtitles filter has its own charenc option, so you can burn an old-code-page file straight into the picture:

ffmpeg -i video.mp4 -vf "subtitles=turkish.srt:charenc=CP1254" -c:a copy output.mp4

On a Mac, Homebrew's default ffmpeg has no libass and reports that the subtitles filter does not exist; install ffmpeg-full and run its binary from $(brew --prefix ffmpeg-full)/bin/ffmpeg. The rest of the burn-in options are in our guide to burning subtitles into a video.

Subtitles show boxes instead of letters: a font problem, not encoding

Boxes mean the text was read correctly and the font has no glyph to draw it. Converting the file changes nothing here.

How it shows up depends on the renderer. We burned a Korean cue styled in Impact, a Latin-only font, with FFmpeg on Windows: libass drew the comma and full stop in Impact and took the Hangul from another installed font. No boxes, but a mixed look you did not choose. Boxes appear when no font on the machine covers the script, which happens on servers and on players with a small built-in font set.

The fix is to name a font that covers the language. In an FFmpeg burn-in that is force_style:

ffmpeg -i video.mp4 -vf "subtitles=korean-utf8.srt:force_style='FontName=Malgun Gothic'" -c:a copy output.mp4

Which system font covers which script on Windows and Mac is listed in our subtitle font guide.

How Sablate handles subtitle encoding and fonts

Sablate writes every subtitle export, .srt, .vtt, .txt and .ass, as UTF-8. A transcription starts in Unicode, so no code page ever enters the file, and the same export reads correctly in Korean, Turkish or Arabic.

Fonts are handled per language. Each translation layer has its own style, and when the caption font you chose cannot draw the script, Sablate substitutes a font that ships with the system: Malgun Gothic on Windows and Apple SD Gothic Neo on Mac for Korean, Yu Gothic UI and Hiragino Sans for Japanese, Microsoft YaHei and PingFang SC for Simplified Chinese. The preview uses the same font as the burn-in, so what you check is what gets rendered.

One honest limit: Sablate's .srt and .vtt import reads files as UTF-8 and does not detect old code pages. Convert an old file with Method 1 or Method 2 before you import it. The feature overview lists the rest of the editor and exports.

For repairing an existing file, the free tools win: FFmpeg and TextEdit read any old code page and Sablate does not. Sablate fits when you are making the subtitles, especially in several languages, and want files that never need this repair.

Which fix should you use?

"One file looks wrong in VLC on my own computer." Change VLC's Default encoding, or convert the file once and stop thinking about it.

"The subtitles have to play on a TV, a phone, Plex or YouTube." Convert to UTF-8 with Method 1 or 2. Other devices will not share your VLC settings, and YouTube's subtitle file page says an SRT "must be in plain UTF-8".

"I see é and ö." The file is already UTF-8. Fix the player, or save a copy as UTF-8 with BOM in Notepad so the file announces its encoding.

"I'm burning the subtitles in." Use charenc in the FFmpeg command, or convert first, then check the font for the language.

"I see question marks." Stop converting and find the original file. The letters are no longer in this one.

How to keep subtitles from breaking again

Save every subtitle file as UTF-8. In Notepad that is the Encoding choice in Save as; avoid ANSI. On a Mac, set TextEdit's saving encoding to UTF-8 once.

Convert before you edit. Editing a garbled file and then converting it mixes two encodings in one file, and the result is much harder to repair.

Keep the original until the converted copy reads correctly where it will actually play: on the TV, in the media server, on the site. If an older device still misreads UTF-8, a copy saved as UTF-8 with BOM usually settles it, because the BOM marks the file as UTF-8 for programs that would otherwise guess.

When you make subtitles from scratch, the encoding is part of making them right. How to make an SRT file covers the save-dialog traps on Windows and Mac.

If you are generating subtitles rather than repairing old ones, start in a tool that writes UTF-8 and picks a font per language for you. Download Sablate for Windows or Mac and export your first file in any of its 100 transcription languages.

Frequently asked questions

Why do my subtitles show weird characters?

Because the player read the file in the wrong character encoding. A subtitle file does not record which encoding it uses, so the player guesses, and a wrong guess turns accented or non-Latin letters into symbols. Convert the file to UTF-8, or tell the player which code page the file was saved in, and the letters come back.

How do I convert a subtitle file to UTF-8?

Open it in a text editor that reads it correctly and save a copy as UTF-8, or run FFmpeg with the file's old code page, for example ffmpeg -sub_charenc CP1254 -i input.srt output.srt for Turkish. FFmpeg writes the new file as UTF-8. Check the result in your player before you delete the original.

How do I change the subtitle encoding in VLC?

Open Tools, then Preferences, then Subtitles / OSD, and pick the file's code page in the Default encoding list. Click Save and restart VLC so the change takes effect. The setting only fixes playback in VLC on that computer, so convert the file to UTF-8 if it also has to play on a TV, a phone or a website.

Why do subtitles show question marks instead of letters?

Because the letters were lost when the text was saved in an encoding that has no place for them. A Korean or Russian subtitle saved as Western European text, for example, stores a question mark for every letter it cannot hold. No conversion brings them back, so you need the original file or a fresh export from the source.

What does Invalid UTF-8 in decoded subtitles text mean in FFmpeg?

It means FFmpeg expected a UTF-8 subtitle file and found bytes from an older code page. FFmpeg's own message suggests the fix: add -sub_charenc with the file's encoding before -i, such as CP1251 for Russian or CP949 for Korean, or use the charenc option of the subtitles filter when you burn the file in.

What encoding should subtitle files use?

UTF-8. It holds every script in one encoding, so the same file reads correctly in any language on any device. YouTube requires SRT files in plain UTF-8, and players, TVs and media servers read it far more reliably than an old Windows code page. If an older device still misreads a UTF-8 file, try saving it as UTF-8 with BOM.