Subtitles showing question marks or garbled characters

What is going wrong

Text files do not record which encoding they use. A byte like0xCF means one letter in Windows-1251 and a different one in Windows-1252, and there is nothing in the file to say which was intended. Software has to guess, and it usually guesses UTF-8 because that is the modern default.

Subtitles, though, are frequently decades old, or produced by tools that still write regional code pages. When a Windows-1251 file is read as UTF-8, each byte that is not valid UTF-8 gets replaced or reinterpreted, and you get mojibake: question marks, black diamonds, or accented Latin letters standing in for Cyrillic.

Identify it from what you see

The pattern to recognise is two Latin characters where one non-Latin character belongs. That is UTF-8 decoding applied to single-byte text, and it tells you the file is a regional code page.

Plain ? or empty boxes usually mean the reverse: the text was converted at some point and the original characters were already lost, or the font in use has no glyph for them. If the characters are genuinely gone, no tool can bring them back and you need a different copy of the file.

Fixing it

Drop the file into Cuelatch. It checks for a byte order mark, tests whether the bytes are valid UTF-8, and if not, scores the plausible code pages against the actual byte distribution. It tells you what it found and lets you override the choice if the preview still looks wrong.

Any file you download is written as UTF-8, which every current player handles, so the problem does not come back.

Doing it by hand

• VS Code: open the file, click the encoding in the status bar, choose Reopen with Encoding and pick the right one, then Save with Encoding as UTF-8.
• Command line:iconv -f windows-1251 -t utf-8 in.srt > out.srt

Changing it in your player instead

Every player worth using can be told which encoding to assume, which gets the text readable in seconds. It is worth being clear about what this does and does not achieve: it changes how that one player reads the file. The bytes on disk do not change, so the problem returns on every other player, every other device, and anyone you send the file to.

In VLC, open Tools, then Preferences, then Subtitles/OSD, and change Subtitle text encoding from Default to the code page the file actually uses. On macOS the same setting sits under VLC, then Settings, then Subtitles. You may need to reload the subtitle track for it to take.

If subtitles are not appearing at all rather than appearing wrong, encoding is still worth ruling out: some players render nothing when decoding fails instead of showing mojibake, so a blank track and a garbled one can have the same cause. On Android that is worth checking againstMX Player subtitles not showing, where a storage permission is the more common culprit.

Do not save it with a BOM

Some editors add a byte order mark to UTF-8 files. Most players cope, but a few show a stray character on the first line or fail to parse the first cue. If your first subtitle misbehaves and the rest are fine, a BOM is the usual culprit. Cuelatch preserves whichever state the file arrived in rather than adding or stripping one behind your back.

If the text is right but the timing is not

Encoding and timing are unrelated problems. Once the characters read correctly, work throughthe timing diagnostic to sort out when the lines appear. If the lines are late or early specifically in VLC, VLC subtitles out of synccovers the delay controls and why the correction does not stick.