How to Fix UTF-8 and Garbled Characters in SRT Files

Garbled subtitle text—often called mojibake—appears when bytes encoded one way are decoded another way. The visible characters are symptoms. Replacing é with é throughout one file may work for a single case but can damage text that was already correct.

Recognize common patterns

Correct: Don’t open the café menu yet.
Broken:  Don’t open the café menu yet.

This often means UTF-8 bytes were read as Windows-1252 and then displayed or saved. Replacement diamonds (�) are more serious: they may indicate the decoder already discarded the original byte information.

Chinese, Japanese, or Korean text decoded incorrectly may produce long sequences of unrelated characters. Do not edit them manually before locating the original file.

Recovery procedure

1. Duplicate the file at the byte level. Work on the copy.
2. Open it in an editor that lets you choose encoding without immediately saving.
3. Try the encoding documented by the source application. Common candidates include UTF-8, UTF-8 with BOM, Windows-1252, Shift_JIS, GB18030, and Windows-949.
4. Confirm several language-specific characters, punctuation marks, and names.
5. Save the corrected text as UTF-8, preferably without changing line endings unless the destination requires it.
6. Validate SRT timestamps and playback.

“Reopen with encoding” and “convert to encoding” are different editor actions. Reopen changes how current bytes are interpreted. Convert changes how correctly decoded text will be written. Reopen correctly first; convert second.

Double-encoding repair

If UTF-8 text was decoded as Windows-1252 and then saved as UTF-8, the wrong visible characters now have valid UTF-8 bytes. Recovery may require reversing that mistaken step: encode the mojibake characters as Windows-1252 bytes, then decode those bytes as UTF-8. Test on a copy and verify characters beyond apostrophes.

Do not disturb timing syntax

17
00:01:02,400 --> 00:01:05,100
Résumé saved — continue to export.

Encoding conversion should leave cue numbers, commas, arrows, and blank separators intact. Smart-editor substitutions can change --> or normalize line breaks, causing an import failure unrelated to text encoding.

Byte-order marks and application quirks

UTF-8 BOM is legal, but some older tools expect it while others mishandle it. Follow the target application’s documented preference. If the first cue number appears as strange characters, inspect for a BOM interpreted as text.

Validation checklist

Search for �, suspicious Ã, Â, or repeated unrelated CJK characters. Compare names against source material. Reopen the newly saved file as UTF-8, then import it into the target editor. Check the first cue because encoding markers affect the file start, and check multilingual lines elsewhere.

Encoding is independent of format. Read SRT vs VTT before converting, and convert YouTube subtitles to SRT for structural conversion. The complete workflow recommends fixing encoding before translation so corrupt text does not enter a translation system.