Garbled Characters in SRT Subtitles: Check Encoding Before Retyping

Before retyping garbled SRT subtitles, preserve the original and compare the same file in a text editor and your target player. A decoding mismatch is one possible cause; missing font glyphs or text already replaced during an earlier save need different remedies.

Diagnose the symptom before converting

Windows-1252 and ISO-8859-1 are different encodings; do not treat their names as interchangeable. A filename does not establish encoding.

Download a small reproducible example

These author-created fixtures contain the same two cues, encoded in two ways:

• UTF-8 sample SRT
• Windows-1252 sample SRT

The intended text is:

1
00:00:01,000 --> 00:00:03,500
Café — déjà vu

2
00:00:04,000 --> 00:00:06,000
Prêt-à-porter & naïve résumé

Reading the UTF-8 sample as Windows-1252 produces this deliberately misdecoded first line:

Café — déjà vu

Reading the Windows-1252 sample as UTF-8 with replacement decoding produces:

Caf� � d�j� vu

A strict UTF-8 decoder instead raises an error. Neither outcome proves that those replacement symbols are stored in the original file.

Reopen a copy in Visual Studio Code

VS Code documents its encoding control in the status bar. Use this documented workflow on a duplicate with Auto Save off:

1. Keep the source untouched and open a working copy.
2. Click the encoding label in the status bar and choose Reopen with Encoding.
3. Select the source encoding. For the supplied Windows-1252 fixture, select Windows-1252; do not apply that choice blindly to other files.
4. Inspect accents and punctuation, cue numbers, timestamps and blank lines.
5. Once the text is correct, use Save As to create a separate candidate file, then use the encoding control's Save with Encoding option to save that candidate as UTF-8.
6. Close and reopen the candidate as UTF-8, then test it in your destination player.

Reopening changes how existing bytes are interpreted. Saving writes the currently decoded text as new bytes. Saving the wrong interpretation can preserve the garble or lose information. These editor steps follow the documentation; the fixture verification below used Python, not a claimed editor or player test.

Verified byte conversion for the supplied fixture

This Python 3.14.2 example was run on the downloadable fixture. Run it in a folder containing the Windows-1252 sample; it creates a separate output and refuses to overwrite an existing candidate:

from pathlib import Path
source = Path("sample-windows1252.srt")
original = source.read_bytes()
text = original.decode("cp1252")
with Path("sample-repaired-utf8.srt").open("xb") as candidate:
    candidate.write(text.encode("utf-8"))
assert source.read_bytes() == original
assert Path("sample-repaired-utf8.srt").read_bytes().decode("utf-8") == text

The decoded output matched the UTF-8 sample, including both cue numbers, timestamps and line breaks. Download that UTF-8 candidate. This establishes the fixture's byte conversion, not successful playback or arbitrary encoding detection. Check your own file in its target player before replacing anything.

Check structure and delivery separately

Character encoding does not repair timing, missing cue separators or wrong words. After the text is readable, use the Subtitle Checker for its supported structural checks. The SRT-to-VTT tool changes subtitle format; do not rely on it to detect or repair arbitrary encodings. See SRT vs VTT for format differences.

YouTube requires plain UTF-8 for SRT uploads. That is a destination requirement, not evidence that every subtitle application behaves identically.

If it still fails

Record the file's source and known encoding, editor and player versions, exact visible text, and whether the original displays correctly elsewhere. Keep original and candidate files separate. If the original characters were already replaced, recover a backup or transcript rather than repeatedly converting the damaged file.