Every one of the five causes below fails the same way: silently. No error dialogue, no warning in a log, no red text. A subtitle format has no version field, no checksum and no way to declare that it is broken, so a player that cannot read one has nothing to report and simply shows nothing — which is indistinguishable from a file with no cues in it.
They are in order of how often they turn out to be the answer.
1. The separator is wrong for the format
This is the one. Open the file in a text editor and look at any timing line.
SubRip writes 00:00:01,000 --> 00:00:04,000. WebVTT writes 00:00:01.000 --> 00:00:04.000. A comma in one, a full stop in the other, and that single character is the whole difference between a working file and a blank screen.
It matters because renaming is not converting. Someone finds that a browser will not take their .srt, renames it to .vtt, and the browser accepts the file, parses it, finds no line it recognises as a timestamp, and renders nothing. The file is loaded. There are zero cues in it. Both statements are true at once, and no interface has anywhere to say so.
The same trap runs in both directions and through two more formats. An .sbv file from YouTube has a comma too — but between the two timestamps rather than inside them — so a tool that looks for the comma rather than for what sits either side of it reads pairs of cues as single cues. And an .ass file from Aegisub has no arrow at all.
The fix: convert rather than rename. The converter handles SubRip and WebVTT in both directions; ASS and SBV have their own pages because each has a second trap of its own.
2. The WebVTT header is missing
A WebVTT file must begin with the word WEBVTT on its own first line. Not after a blank line, not after a comment, not after a byte-order mark: first.
A file without it is not a WebVTT file, whatever it is called and whatever is in the rest of it. Browsers are strict about this in a way they are about very little else, and it is the second thing to check after the separator — because a converter that fixes the full stops and forgets the header produces a file that looks entirely correct and still shows nothing.
3. Three invisible bytes at the start
If the first subtitle never appears and every other one does, stop looking at the timings. This is a byte-order mark.
It is three bytes — EF BB BF — written at the very start of the file by some editors and by Notepad on Windows to declare the encoding. Nothing displays them. They are not a space, not a newline, not a character you can put a cursor next to. What they do is attach themselves to whatever comes first, which in a SubRip file is the index number of the first cue. 1 becomes something that is not 1, that block fails to parse, and cue one is quietly dropped.
The reason this is so hard to find by looking is that the file is perfect. Every editor shows exactly what you expect. The three bytes are the same three bytes that break a CSV, approached from the other side: there they make Excel read the file correctly, and here they cost you a cue.
4. The encoding is not UTF-8
If the subtitles appear but the accented characters are wrong — é whereé should be, or a row of question marks where Arabic or Cyrillic should be — the file is not saved as UTF-8, or is being read as though it is not.
A subtitle file has no way to declare its own encoding. There is no header field for it in SubRip and no reliable one in WebVTT, so a player has to guess from the bytes. Modern players guess UTF-8 and are right most of the time; a file saved twenty years ago in a regional encoding is a file they will guess wrong. Re-saving as UTF-8 is the permanent fix, and it is the only one — every other approach is a per-player setting that has to be repeated on every device.
5. The player never selected the track
The unglamorous one, and it costs more hours than the byte-order mark.
Most players match a subtitle file to a video by file name. The subtitle file has to sit in the same folder and share the video’s name exactly, with the language code and the extension after it: film.mkv and film.en.srt. One character of difference — a stray (1) from a second download, a different release tag — and the player never associates the two, then reports nothing, because as far as it knows there are no subtitles to report on.
And even when it is found, a track has to be turned on. A file with several embedded tracks starts on whichever the container marks as default, which is frequently not yours.
The order to check in
All five take about a minute together, and the order matters because each rules out the next.
- Is anything at all appearing? If some cues show and some do not, it is not a format problem — go to the byte-order mark, or to a damaged block partway through.
- Open the file in a text editor. Does the first line say
WEBVTTwhere it should? Do the timing lines use the separator the extension implies? - Are the characters right in the editor? If they are wrong there too, it is the encoding rather than the player.
- Does the file name match the video? Exactly, character for character, before the language code.
- Only now consider the timing. Subtitles that are present but invisible are a different fault from subtitles that are present at the wrong moment — and if a cue only appears for a tenth of a second, it did show up and you missed it.
That last one is the boundary between this article and the next. Subtitles that appear at the wrong time have their own two causes and their own two fixes, and applying the wrong one makes the file worse rather than leaving it unchanged.
Why none of this reports an error
It is worth understanding the shape of the problem rather than only the list, because the list will not cover the sixth case.
A subtitle file is plain text with a convention laid over it. There is no header declaring which convention, no version number, no length field, nothing to check the file against itself. A parser reading one has exactly two states available to it: this line looks like a cue, or it does not. A file where nothing looks like a cue is therefore, to the parser, a valid file containing no cues — which is a perfectly legal thing for a subtitle file to be.
So the error is not suppressed. It is never detected, because at no point does anything know that a cue was expected. That is why every fix here is something you find by looking at the file rather than by reading a message, and why a tool that tells you what it read — read as SBV, 3 cues, 1 skipped — is doing the one thing the format cannot do for itself.