Subtitles look fine in VLC on my computer but turn to garbage on my phone or TV. Why?

Players assume different default encodings for subtitle files that don't declare one. Desktop VLC has a Default encoding setting and may be reading your legacy-codepage file correctly, while the TV or phone app assumes UTF-8 and misreads the same bytes. Rather than configuring every device, convert the file itself to UTF-8 once; then every player reads it the same way.

Garbled Subtitles? Fix Broken Subtitle Encoding (UTF-8, EUC-KR, Shift-JIS & Mojibake)

You open a subtitle file and the timestamps are fine, but the dialogue reads ì•ˆë…•, cafÃ© or a row of ???. It looks corrupt, but usually the text is all there and is being decoded with the wrong character map.

What "encoding" means

A subtitle file is a sequence of bytes. A character encoding is the table that turns those bytes into letters. The same byte means different things in different tables, so a file written with one encoding and read back with another shows every non-English character wrong, even though the file itself is fine.

You'll meet two kinds of encoding:

UTF-8, the modern universal encoding. It covers every language and is what current players, editors and platforms expect. Non-English characters take several bytes each.
Legacy codepages, older tables that each cover one language group:
- Korean: EUC-KR and CP949 (also called UHC or Windows-949, a superset of EUC-KR)
- Japanese: Shift-JIS (CP932)
- Simplified Chinese: GB2312, GBK (CP936) and GB18030 (a backward-compatible superset, not the same as CP936)
- Traditional Chinese: Big5 (CP950)
- Western European: Windows-1252 and ISO-8859-1 (Latin-1)
- Cyrillic: Windows-1251

The garbled result has a name, mojibake, borrowed from Japanese.

Diagnosis: what the garbage tells you

What you see	What it means	Recoverable?
Readable but wrong characters: `ì•ˆë…•`, `cafÃ©`, `Ð¿Ñ€Ð¸`	Mojibake: right bytes, wrong decoder	Yes, by re-decoding with the correct encoding
`?` or `�` (replacement diamonds) stored in the file	An earlier save re-encoded lossily and the original bytes are gone	Usually not; re-export from the source
Empty boxes ("tofu"): `□ □ □`	A missing font, not an encoding problem	Install or embed a font that has those characters

The first row is the most common and is fixable. Mojibake runs in two opposite directions, and the look of the garble tells you which one you have.

UTF-8 read as a Western codepage gives accented-Latin soup. The file is already UTF-8, and a player or editor is decoding it as Windows-1252:

A UTF-8 Korean file shows ì•ˆë…•: each Korean character's three bytes are drawn as separate Latin symbols.
A UTF-8 café shows cafÃ©, because é is the two bytes C3 A9, which Windows-1252 draws as Ã and ©.

The bytes are right, so the fix is to make the tool read the file as UTF-8.

A legacy codepage read as UTF-8 gives the reverse, and this is the usual cause of broken Korean, Japanese and Chinese subtitles. An old EUC-KR/CP949, Shift-JIS or Big5 file opened by a UTF-8 tool shows � marks or scrambled characters. Re-open it declaring that legacy codepage, then save as UTF-8.

One case looks like the first but isn't. If the Latin soup is still there when you open the file as UTF-8, someone decoded it wrongly and then saved it, so the soup itself is now stored in the file (double encoding). Re-decoding won't fix that. The Python library ftfy can often reverse it; otherwise re-export from the source.

In every case the timestamps stay clean. The characters an SRT uses for its structure (digits, the : and , in timestamps, the --> arrow, line breaks) have the same bytes in UTF-8 and in these legacy codepages. Clean timing with garbled words means an encoding problem, not a corrupt file.

How to fix recoverable mojibake

The fix always has the same shape: re-open the file declaring its real encoding, confirm the text reads correctly, then save it as UTF-8. Use whichever tool you have and try encodings until the preview is right.

Subtitle Encoding Converter (free, in your browser)

Open the Subtitle Encoding Converter and choose the garbled file (SRT, VTT, ASS, SBV and SMI all work). It pre-selects its best guess at the source encoding; if the preview doesn't read correctly, step through EUC-KR/CP949, Shift-JIS, GB18030/GBK, Big5 and Windows-1252/1251 until it does, then download the file as UTF-8 without a BOM. The file is read in your browser and never uploaded.

Notepad++ (free, Windows)

Open the file. Under Encoding → Character sets, pick the entry that makes the text readable (for example Korean → EUC-KR for an old Korean file). This reinterprets the existing bytes. If the file is really UTF-8 showing Latin soup, choose Encoding → UTF-8 instead.
Check that the text now reads correctly.
Choose Encoding → Convert to UTF-8 (not "UTF-8-BOM").
Save.

VLC (any platform)

In Preferences → Subtitles / OSD → Default encoding, set the file's real codepage, for example Korean (EUC-KR/CP949). This only fixes the display while VLC plays the file. The file itself isn't rewritten, so other apps still see the original bytes.

iconv (command line, macOS/Linux)

iconv -f EUC-KR -t UTF-8 broken.srt > fixed.srt

Swap EUC-KR for SHIFT-JIS, GBK, BIG5, WINDOWS-1252 and so on. If iconv stops with a conversion error on a Korean file, try CP949, which covers characters that plain EUC-KR doesn't.

Whatever you use, save as UTF-8 without a BOM (see below). Once the file is clean UTF-8, you can convert it to VTT, pull a plain-text transcript, or fix its timing if that's off too.

The BOM trap

Some editors put a byte order mark at the start of a UTF-8 file: three invisible bytes, EF BB BF. UTF-8 doesn't need one, and in an SRT it sits right before the first cue number, so some parsers fail to recognize cue 1 or show a stray ï»¿ (the BOM drawn as Windows-1252 characters) before the first subtitle.

When an editor offers both, choose "UTF-8" over "UTF-8 with BOM" or "UTF-8-BOM". In Notepad++ that's Encoding → Convert to UTF-8.

When the text is gone

If the file contains literal ? or � characters stored in the bytes (not just shown on screen), a tool earlier in the chain saved it in an encoding that couldn't represent those characters and put a placeholder in their place. That conversion is one-way. The original characters aren't in the file any more, and re-decoding can't bring them back.

What you can do:

Re-download or re-export the subtitles from the original source, saving as UTF-8 this time.
Transcribe the video again, which sidesteps the broken file.

Korean, Japanese and Chinese files

This problem is most common with Korean, Japanese and Chinese subtitles, because those languages had widely used codepages before UTF-8 (EUC-KR/CP949, Shift-JIS, GBK, Big5). A Korean SRT from an older download site is often CP949, and a UTF-8 player or editor shows � marks or scrambled characters instead of Korean. Reinterpret it as CP949 (or EUC-KR), save as UTF-8, and it works in any modern player.

Starting from the video instead

Every mojibake problem starts with reusing a file that was saved in some legacy codepage. A subtitle file generated new from the video's audio doesn't inherit that history. Picute transcribes a video file or a YouTube link in 60 languages and exports SRT, VTT, or an MP4 with the subtitles burned in.