SRT is the subtitle format everything reads, and the simplest one. VTT is WebVTT, the only subtitle format a browser reads natively. ffmpeg sits between the two, and this page says exactly what happens to an SRT file on the way to becoming a VTT one.
What runs when an SRT file becomes VTT
ffmpeg held to a single thread, on a machine we rent and watch. Your SRT file is uploaded once, ffmpeg runs once, the VTT comes back, and neither file is kept. SRT to VTT is one of the 3649 pairs that engine was probed on with a real file, which is why it has a page here and why the pairs the probe could not prove do not.
What survives from the SRT into the VTT
Every line, and the moment it appears. The engine reads your SRT and writes the same cues into the VTT: the text is not re-wrapped, the order is not touched, and the start of each cue lands where it was. It counts the cues on the way out and refuses the result if the count moved.
Accents and every other character. The VTT is written as UTF-8, which is the one thing that stops subtitles arriving as question marks on a machine that is not yours.
A file whose size you can predict. We put the same 200-cue file through all six formats and weighed what came out: 78.5 bytes per cue in VTT, 11 % smaller than the SRT, because it is the same file without the cue numbers, which WebVTT does not ask for. Smaller is not better here. It is the consequence of carrying less, and the next section says what.
End times as well as starts, exactly as your SRT had them. Nothing is recomputed.
The ability to use it on a web page. VTT is the only subtitle format the HTML track element accepts, so this pair is not a preference but the requirement for putting subtitles on a video in a browser.
What SRT to VTT costs you
Nothing measurable, which is worth saying plainly. SRT and VTT carry the same cues with the same fidelity, and this pair changes the container rather than the content.
Where SRT and VTT files come from
SRT. Written for SubRip, a Windows program that pulled subtitles off DVDs, and it won by being trivial: a number, two timestamps, the lines, a blank line. No styling, no specification, no committee. Every player on earth reads it.
VTT. A W3C standard, and the only format the HTML track element accepts. If subtitles are going on a web page, this is not a preference but a requirement. It is SRT with a header line, dots instead of commas, and optional styling and positioning.
If a model is going to read the VTT
A subtitle file is a transcript with the clock attached, which is what makes it worth feeding to a model at all: every line comes with the moment it was said. SRT in, VTT out, and the START of every line lands where it was, so a question like "what was said at eleven minutes" still has an answer afterwards.
SRT to VTT, measured rather than promised
Running SRT to VTT against the real engine with a real file, ffmpeg wrote 128 bytes of VTT in 0.1 seconds, machine otherwise idle. That is one SRT file on one day and not an average, which is why the number is given together with the file that produced it.
The SRT to VTT verdict was reached by reading the text, the timings and the length of every cue, meaning the output was read back and recognised. Which check was used matters, because they do not all prove the same thing, and a status code of 200 proves nothing whatsoever about whether the VTT file has anything inside it.
Other ways into VTT, and what they measured
Among the published routes into VTT, SRT is the first largest output of the 2 measured. The witness files differ, so this ranks the probe run and not your document.
ASS to VTT: 128 bytes in 0.1 seconds.
What we will not pretend about SRT to VTT
An SRT file over 5 MB is refused before the upload finishes rather than after it, so you do not wait for a rejection.
An SRT to VTT run that passes 30 seconds is killed, and the ffmpeg process is killed with it. A run left behind would sit on one of the machine's two cores until somebody noticed.
This family does not touch the timing itself. Shifting subtitles by two seconds, stretching them for a different frame rate or merging two files are real needs and none of them happens here: this converts a container into another container.
One SRT file at a time, chosen in the browser. There is nothing else to set up and nothing else on offer.
SRT to VTT: what people ask
What actually converts my SRT file to VTT?
ffmpeg does it, held to a single thread, on a machine we rent and watch. Not a browser trick and not somebody else service: the SRT file is uploaded once, ffmpeg runs once, the VTT comes back, and neither file is kept afterwards.
How long does SRT to VTT take?
On the file the probe used, ffmpeg took 0.1 seconds and wrote 128 bytes of VTT. That is one real measurement on one real SRT file, not an average and not a promise about yours: a larger SRT takes longer, and past 30 seconds the run is stopped.
What do I lose going from SRT to VTT?
The one to know about first: Nothing measurable, which is worth saying plainly. SRT and VTT carry the same cues with the same fidelity, and this pair changes the container rather than the content.
Will the timings still match my video?
Yes. The start of every cue is carried across unchanged, not recomputed. The ends too, exactly as your file had them.
Why does my video player not read the SRT directly?
A browser will not. The HTML track element accepts WebVTT and nothing else, which is why this conversion exists: it is not a matter of preference but the requirement for putting subtitles on a video in a web page.
Is SRT to VTT free?
There is a free allowance every month, and one SRT to VTT conversion costs half a credit against it. When the allowance runs out the tool says so and stops, rather than quietly handing you a worse VTT.