Why Are Subtitles Garbled?

Subtitles turn into boxes, question marks or a garbled string in one player, and most people's instinct is "the file broke." Usually it didn't — the encoding, line endings or a file-header marker just don't match the player. Check in the order below and the cause usually pinpoints itself; every step has a clear verdict, so you're not guessing.

First, classify: garbled or malformed?

Text becomes boxes, question marks, twisted symbols, but the cue count and structure are intact — that's an encoding problem, and what this article handles. If instead the index and timeline mismatch or cues fly off wholesale, that's a format or timing problem — run it through the subtitle checker or the subtitle cleaner. Separate the two categories first, or the investigation drifts.

Step one: confirm the encoding — prefer UTF-8 without BOM

Most modern players and platforms read files as UTF-8 by default. If the file is GBK or UTF-8 with BOM, older players render wrong characters.

Re-save the file as "UTF-8 (no BOM)" in an editor — in Notepad's save dialog, pick UTF-8, not "UTF-8 with BOM". Chinese, Japanese and Korean subtitles especially must be UTF-8, or garbling is guaranteed. Unsure of the current encoding? Open it in an editor with encoding detection (VS Code, say) — the status bar shows the actual encoding; save-as to the target one from there. Reopen in the player and see if the boxes are gone.

Verdict: if the whole file turns into boxes or garbage — not just a few characters — it's almost certainly encoding. If only the Chinese garbles while English stays fine, the Chinese encoding wasn't recognized; again encoding, not line endings. Subtitles exported by SmileSub default to UTF-8 and work across platforms. For SRT's standard layout, see bilingual SRT format explained.

Step two: check the line endings

Windows uses CRLF (\r\n); Unix and macOS use LF (\n). A few old tools accept only one kind — wrong endings glue cues together.

Toggle invisible-character display in your editor, see whether lines end in LF or CRLF, and unify to whatever the target platform expects — usually LF travels better. Save, reload the subtitles.

Verdict: if cues no longer separate and whole blocks stick together, it's most likely the line endings, not the encoding.

Step three: the BOM at the file head

A BOM is a few invisible bytes at the start of the file that mark the encoding. Most tools ignore it, but a few players render it as a garbled string before the first cue.

Remove it with a hex view or "save as UTF-8 without BOM". If the weird characters before the first cue disappear afterward, it was the BOM. Export without BOM from then on and the issue never returns.

Verdict: a few strange characters before the first cue only, everything after normal — that's the BOM misbehaving.

Fixing and preventing

The check order is fixed: encoding → line endings → BOM; outermost layer first, file head last. Cross-system copies (between Windows and macOS) are the likeliest trigger of auto-converted encoding and endings — export on the target system when you can.

Reduce the daily workflow to one line: save as UTF-8 without BOM, lines as LF, and every later stage gets easier. After export, open it once in a player and once in an editor, confirm Chinese, Japanese and Korean all render, then hand it downstream. One more trap: never switch encodings mid-edit — once a UTF-8 file gets saved as GBK even once, the garbling is welded into the content and only a re-export from source fixes it.

For choosing between subtitle formats, see the subtitle format chooser guide.

FAQ

Why does the same SRT play fine in one player and garble in another?

Usually an encoding or BOM difference. Players handle UTF-8 and BOM inconsistently; normalizing to UTF-8 without BOM usually fixes both sides.

Do line endings really affect display?

Most modern software tolerates both endings, but some old tools or embedded players accept only one, gluing cues together or scrambling the timeline — worth checking.

How do I prevent garbling at the source?

Save and export as UTF-8 without BOM, lines as LF, and avoid passive conversion from copying between systems. Subtitles exported from online tools are already handled to this standard.