Subtitles are one of those areas where everything looks interchangeable and nothing quite is. A file plays perfectly in a desktop player, gets uploaded to a web page, and silently does nothing. Another one loads but has every accented character mangled. A third comes out of a video file and refuses to become text at all.
Each of those has a specific cause, and none of them is the player being fussy.
One format was specified, the other was just written
SubRip files are named after a Windows program from the late 1990s that pulled subtitles off DVDs. There is no standards document behind the format. It is simply whatever that program wrote, and everything since has copied it: a number, a timing line, one or more lines of dialogue, a blank line, repeat.
That informality is exactly why it became universal, and also why its edge cases are decided by whichever player you happen to open the file in. Two players can disagree about a malformed file and both be defensible, because there is no document to appeal to.
WebVTT went the other way. It was written up as a specification because browsers needed something they could parse consistently for the HTML5 track element, and a specification means real rules: a mandatory file signature, a defined encoding, named cue settings, an optional identifier line. Anything claiming to be WebVTT that breaks those rules is ignored rather than guessed at.
The everyday consequence is a mismatch nobody plans for. Editing software exports SubRip because that is still its default. Browsers and every JavaScript player built on them want WebVTT and will quietly drop a track that is not.
The first line is the whole problem
The single most common subtitle failure on the web has a one-line explanation: a WebVTT file must begin with the literal text WEBVTT, optionally preceded by a byte order mark.
It is the format’s magic number. A browser that does not find it treats the file as not-WebVTT and stops, which is why a hand-renamed SubRip file produces a video element with a caption menu that does nothing at all. The content parses fine to human eyes and fails on line one for the parser, and nothing anywhere reports an error.
Converting properly writes that header. Going the other direction it disappears, along with everything else that is not a cue, through a mechanism worth understanding because it explains several behaviours at once: the parser only recognises a block as a cue if it contains a timing line. The header has none, so it produces nothing. Comment and style blocks have none either, so they vanish by the same rule rather than needing special handling.
Commas, dots, and the hour that is sometimes missing
Both formats measure time in hours, minutes, seconds and milliseconds, so precision is never the issue. SubRip separates the milliseconds with a comma and WebVTT with a full stop.
The asymmetry is in what each allows you to omit. WebVTT permits an abbreviated timestamp with the
hours left off, so a cue can legitimately start at 02:15.500. SubRip has no such allowance, so
every timestamp has to be written out complete and zero-padded, and that cue becomes 00:02:15,500.
Converting between them properly means parsing to a number of milliseconds and reformatting, rather than patching the text with a search and replace. That is what makes a round trip come back byte-identical, and it is why our SRT to VTT converter works on parsed values rather than on strings.
Cue identifiers travel in one direction only, for a similar structural reason. SubRip’s leading
number is mandatory; WebVTT’s identifier line is optional, and most machine-generated caption files
have none. So going to WebVTT the numbers are kept, and coming back the identifiers are discarded
and cues renumbered from one. Reusing them was never viable: a file with no identifiers has nothing
to reuse, and one with identifiers like intro and outro would produce a SubRip file no player
indexes correctly.
What SubRip cannot express
WebVTT can place a caption. Settings after the timing line control alignment, vertical position, line placement and size, and none of that has a SubRip equivalent, so it is dropped on conversion. Styling blocks go the same way.
This matters when captions are doing something other than transcribing dialogue. A translation of on-screen text usually needs to sit near that text; a speaker label in a two-person interview may be positioned to match. Converting such a file down to SubRip keeps every word and loses the information about where the words belong.
The richer formats go further still. ASS and SSA, which came out of the fansubbing world, carry full styling, fonts, colours, positioning and karaoke timing, and are the reason some anime releases have captions that look typeset rather than pasted on. Converting one to SubRip keeps the text and discards everything that made it look designed.
The formats that are pictures, not text
Here is the distinction that explains the most confusing failure of all.
Not every subtitle track contains text. DVD and Blu-ray subtitles store each cue as a rendered bitmap: a small picture of the words, already typeset, with transparency. The player composites the image over the frame. There are no characters anywhere in the file.
That is why extracting subtitles from a video has to distinguish between two groups of codecs rather than treating every subtitle stream alike. Text-based streams, which include SubRip, ASS, SSA, the MP4 text format and WebVTT, carry actual cue text and can be converted losslessly to a text subtitle file. Image-based streams, which include DVD subtitles and the Blu-ray presentation graphics format, cannot, because there is nothing to convert. The honest behaviour is to identify the track, report what it is, and decline, rather than to produce an empty file and let you discover the problem later.
Getting text out of those tracks is possible, but it is an optical character recognition job run over thousands of small images, with all the accuracy caveats that implies. It is a different problem in a different domain, not a format conversion.
Timing is a separate problem from format
A file can be in exactly the right format and still be useless because the words arrive at the wrong moment, and the two failures need different fixes.
There are two distinct timing problems. The first is a constant offset: every subtitle is two seconds late, usually because the video has an intro the subtitle author did not have. The fix is to add or subtract a fixed amount from every timestamp.
The second is drift, where the subtitles start correct and gradually diverge, ending up wildly out by the end of a feature. That is a frame rate mismatch: the subtitles were timed against a version of the video running at a different rate, most commonly a film transferred at 25 frames per second against one at the fractional broadcast rate near 24. The error is proportional to elapsed time, so no fixed offset fixes it. What is needed is a multiplication.
Shifting subtitle timing does both, and the order matters. The stretch is applied first and the offset second, which is the standard scale-then-translate form: a new timestamp is the original multiplied by the ratio, plus the offset. Doing it the other way would scale the offset by the ratio too, which is not what anyone means when they ask for a two second shift. It shares its timestamp parsing with the conversion tool, so a millisecond means the same thing in both.
Soft tracks and burned-in captions
The last decision is whether the subtitles stay a separate thing at all.
A soft track is a separate file, or a separate stream inside the container, that the player renders at playback time. It can be turned off, restyled, corrected, or swapped for another language, and the video itself is untouched.
Burning captions in draws them into the picture permanently. There is no toggle and no correction afterwards, and because every frame has to be redrawn, the video is fully re-encoded, which costs a generation of quality and real time. Adding subtitles to a video does exactly this, and the re-encode is unavoidable rather than an implementation shortcut: changing what the picture shows means rewriting the picture.
The reason to accept that cost is reach. Most social video feeds discard external subtitle tracks on upload, and a large share of viewers watch with the sound off, so a burned-in caption is the only one that will actually be seen. The sensible habit is to keep the soft track as your master and burn a copy for the platform, rather than burning first and losing the editable version.
