SRT vs VTT — which subtitle file do you need?

Both are plain text with timestamps

An SRT file is a numbered list of blocks. Each block has an index, a start and end time like `00:00:01,000 --> 00:00:04,000`, and the lines of text to show. That is the entire format. Its simplicity is why it turns up everywhere — media players, TVs, editing software, video platforms.

VTT is the same idea rewritten for the web. It was standardised so browsers could display subtitles natively on an HTML video element, and it adds room for things SRT never had a place for.

The differences, in full

There are not many, and they are all mechanical:

• A VTT file must begin with the line `WEBVTT`. If that line is missing the browser rejects the whole file — this is the single most common reason subtitles silently fail to appear.
• Fractions of a second are separated by a comma in SRT and a full stop in VTT.
• SRT requires the block numbers. VTT treats them as optional labels.
• VTT can carry position, alignment, styling and speaker identification. SRT has no notion of any of that.
• The HTML5 video `<track>` element accepts VTT only. It will not load an SRT.

So which one do you want

If the video is playing on a web page you control, VTT — you have no choice. For everything else, SRT is the safer file: desktop players, phones, TVs, editing software and every major video platform accept it, and several of them do not accept VTT.

Because the conversion is mechanical, it is not worth agonising over. Our subtitle tool writes both files from the same transcript, so you can take whichever the destination wants.

How automatic subtitles are produced — and how they fail

Generated subtitles come from a speech recognition model. The audio is decoded, resampled to 16 kHz, and passed to the model, which returns text along with the time each segment started and ended. Here that happens inside the browser tab, which means the model has to be downloaded first — 151 MB or 291 MB depending on which you pick — so the tool states the number before you start rather than after.

The failure mode worth knowing is that poor audio does not produce slightly worse text; it produces a loop. We fed it a 1948 speech recording and it returned the same syllable over and over. A clean modern recording in the same language got roughly forty words with two mistakes. That was recording quality, not language difficulty — and because it is the failure people will hit most often, it is a permanent warning on the page rather than a note in an FAQ.

The most expensive mistake, though, is the language selector. Point a recognition model at the wrong language and it does not stop; it produces fluent, confident nonsense — we measured an English recording transcribed as a hundred and twenty lines of Korean gibberish. If the transcript reads like plausible text that has nothing to do with the audio, check that first.

Translating subtitles is a separate job

Translation runs a different model again — a 418-million-parameter multilingual one that handles a hundred languages in any direction. It is small enough to run in a tab, and that size sets the quality.

The honest description: of twenty lines, about fifteen come out well and five are awkward but understandable. Ordinary sentences are fine. Idioms are where it slips — "let's wrap this up" came back meaning roughly "let's get started" in both Spanish and German, which is not a small error.

Very short exclamations are the one case where it does not merely slip but collapses into repetition. Rather than ship that, the tool detects the collapse and leaves the original line untranslated, so you can see which lines need a human.