Why subtitles turn into gibberish
A text file is just bytes; an encoding is the table that turns those bytes into letters. For decades,
subtitles were saved in regional single-byte encodings — Cyrillic in Windows-1251, Arabic in Windows-1256, Greek in
ISO-8859-7, Western European in Windows-1252. Today’s players assume UTF-8, so they read the old bytes through the
wrong table and you get здравеÐthemed nonsense, accented soup, or the replacement character
�.
Detect, preview, re-save as UTF-8
Drop the file and the tool guesses the original encoding by analysing which scripts the bytes resolve to and how closely they match real letter frequencies. The before/after preview shows the garbled text next to the repaired text, cue by cue, so you can confirm at a glance. The download is clean UTF-8 that any modern player reads.
read as UTF-8 (wrong) decoded as Windows-1256 (right)
الترجمة الترجمة العربيةDetection is a best guess — short files are genuinely ambiguous between similar encodings — so when the preview still looks off, pick the encoding from the dropdown and it updates live.
The “é” case: double-encoded UTF-8
A nastier failure: text that was already UTF-8 got read as Windows-1252 and saved again. Now “café” reads “café” and a curly apostrophe becomes “’”. The file passes as valid UTF-8, so naïve detectors leave it alone. This tool recognises the pattern and reverses the extra layer automatically, with a note when it does.
Clean output
- UTF-8 out — the universal default; works in modern players, editors and the web.
- Optional BOM — off by default; enable only for the rare Windows player that needs it.
- Structure untouched — only the text encoding changes; timing and cues are preserved. Fix structural problems next with the SRT repair tool.
- Private — detection and conversion run locally; nothing is uploaded.