The file is fine — it was read wrong
What a subtitle file stores is bytes. Turning bytes into characters requires knowing which encoding they were written in — get that wrong and you get mojibake. Not one byte is missing from the file; read it again with the right encoding and the characters come back.
That splits the job in two: working out what encoding it started as, and saving it as an encoding your player can detect. The first comes from trial decoding and scoring, the second from saving a copy. They solve different problems.
Five looks, five causes
Mojibake is not random — how it looks gives away what caused it:
- Clumps of accented letters (`ä½ å¥½`): UTF-8 Chinese read as a single-byte encoding — Chinese takes three bytes per character in UTF-8, and reading one byte at a time turns each byte into its own letter
- Runs of CJK characters with not one common one among them: UTF-8 read as GBK — the bytes get regrouped in pairs and every pair lands on some obscure character
- A pile of currency and maths symbols: bytes landed in the symbol range, typical of being read as Mac Roman or some Latin-1 variant
- Control characters mixed in: bytes landed in the invisible control range, showing up on screen as blanks or boxes
- The boxed question mark `�`: that is the replacement character, not mojibake — it means "there was a character here, and it was already lost when this was read"
Why the replacement character cannot be repaired
The replacement character is the dividing line. A `�` means the bytes were already thrown away at an earlier step (usually some program reading the file and saving it again), and nothing was recorded about what got dropped. At that point there is nothing to reason backwards from — nobody can repair it.
So the repair page handles two cases differently. Upload a file and the original bytes are intact, letting it try each encoding; if pasted text already contains the replacement character, it says so plainly: "cannot be repaired, please upload the original file".
There is also the reverse case: the content reads perfectly well but your player still shows garbage. The file is not at fault — the player picked the wrong encoding. Editing the text will not help; save a copy as UTF-8 with BOM or GBK and hand it that.
What it is comparing while repairing
The tool tries every plausible encoding, then scores each result: how much of it is made of common characters, whether there are strings of accents, strings of symbols, whether the CJK runs are walls of obscure characters. The best-scoring result goes to the top of the list.
If no score is clearly better, nothing is recommended — better to tell you "this reads fine as it is" than to fob you off with something that only vaguely resembles language. Text mangled twice (saved wrong once, then repaired wrong once) gets one extra round of back-solving on the top candidates.
Saving the right encoding finishes the job
Repaired text still has to be saved as an encoding your player recognises. Players on Windows usually rely on the BOM to detect encoding, so UTF-8 with BOM is the least fuss; older hardware and some regional players want GBK. You can pick UTF-8, UTF-8 (with BOM), GBK, Big5, Shift_JIS or EUC-KR, and you will be told to choose another if something does not fit (GBK cannot hold Korean).
Related tools and guides
The full walkthrough — How to repair mojibake subtitles; what an SRT file actually stores — What is inside an SRT file; the encoding is fine but the content is dirty (watermarks, ads, hearing-impaired tags) — Subtitle cleanup.