Two Reasons Subtitles Show the Wrong Characters
Garbled letters and stray markup look similar and have nothing in common. How to tell encoding faults from escaping faults, and why SRT and WebVTT disagree.
"My subtitles show the wrong characters" describes two completely different faults with different causes and different fixes. People reach for the wrong one constantly, so it is worth being able to tell them apart in a few seconds.
Fault one: the characters are garbled
You see ’ where an apostrophe should be, or question marks and boxes where accented letters should be. Whole words are unreadable. This is an encoding problem: the file was saved in one character encoding and is being read in another.
The fix is to save as UTF-8, and the important part is not to re-save a file that is already garbled, which bakes the damage in. The guide to subtitle encoding covers it properly.
Fault two: the characters are correct but the markup shows
The letters are all right. What appears instead is machinery: & in the middle of a sentence, or a tag like <v Priya>sitting in front of the dialogue, or half a line vanishing after an innocent "5 < 10".
That is not encoding. That is one format's rules being applied to another format's text.
Why the two formats disagree
SRT has no escaping rules at all. An ampersand is an ampersand and an angle bracket is an angle bracket. There is nothing to get wrong.
WebVTT does have rules, because it reserves both characters. < opens a cue span and &opens a character reference. So text that is perfectly valid in SRT is not valid inside WebVTT, and the failure is quiet rather than loud: a line reading "5 < 10 and then some" can lose everything after the bracket, because a parser reads it as the start of a tag that never closes.
A converter that copies the text straight across produces a file that looks fine in the editor and renders wrong in the player. Ours escapes on the way in:
SRT in: Fish & chips, 5 < 10
WebVTT out: Fish & chips, 5 < 10And unescapes on the way back, so a round trip returns the characters you started with rather than the machinery.
Which tags survive, and which do not
Italic, bold and underline are valid in both formats and are the only markup SRT players broadly agree on, so they pass through untouched.
<font color="#fff"> is common in SRT files and is not WebVTT at all. Its tags are dropped and the text inside is kept, which is better than showing a viewer a raw tag. Anything else in angle brackets is escaped rather than deleted, so it displays as the author wrote it instead of silently swallowing the rest of the line.
<i>italic</i> and <font color="#fff">coloured</font> and <weird>
becomes
<i>italic</i> and coloured and <weird>The SRT to VTT converter reports what it did rather than doing it silently, so you can see how many characters were escaped and how many font tags were dropped before you ship the file.
Telling them apart in ten seconds
Open the file in a plain text editor and read one cue.
If the words themselves are unreadable, with strings like é where a letter belongs, it is encoding. If the words are perfectly readable and there is extra machinery around them, entities or tags or a truncated line, it is markup.
The reason this matters is that the fixes do not overlap. Re-saving as UTF-8 does nothing for a stray &, and escaping does nothing for mojibake. Diagnosing the wrong one costs an afternoon.
Once the file is clean, the subtitle validator will check line lengths and reading speed, and the caption generator will build a fresh track if the file turns out to be beyond saving.
Quick answers
What is the difference between an encoding fault and an escaping fault?
One damages the letters and the other adds machinery around them. If you cannot read the words, the file was written in one character set and opened in another. If you can read them perfectly but there is a stray entity or a tag in the way, the text is intact and something has applied the wrong format's rules to it. Fixing the wrong one changes nothing, which is why the distinction is worth thirty seconds.
Why does an ampersand cause a problem in WebVTT but not in SRT?
Because only one of the two formats gives those characters a job. In SRT they are ordinary text. In WebVTT an angle bracket begins a tag and an ampersand begins a character reference, so the parser stops treating them as content. The dangerous part is how quietly it goes wrong: a bracket that never closes can take the rest of the line with it and nothing reports an error.
Which formatting tags survive a conversion to WebVTT?
The three that both formats agree on: italic, bold and underline. Colour tags do not survive, because they were never WebVTT to begin with, so the tag goes and the words inside stay. Anything else unrecognised is neutralised rather than deleted, so the reader sees what the author typed instead of losing a sentence to it.
Will converting back to SRT leave entities in my file?
No. The conversion back unescapes, so a round trip returns the characters you started with rather than the machinery. An ampersand that became & on the way into WebVTT comes back as an ampersand.
How do I tell which fault I have?
Open the file in a plain text editor and read one cue. Unreadable words mean encoding. Readable words with extra tags or entities around them mean markup.