SRT vs VTT: which subtitle file do you actually need?

SubRip Text: a numbered list of cues, each with a start and end time and one or more lines of text. Timecodes use a comma before the milliseconds — 00:01:23,400 — which is the single most common reason a hand-edited file is rejected.

It has no styling, no positioning and no metadata. That poverty is exactly why it is universal: there is nothing in an SRT for a player to disagree about. Twenty-year-old software reads it and so does everything shipped this year.

Two practical notes. Cue numbers should be sequential, and most players tolerate gaps but some do not. And an SRT saved as anything other than UTF-8 will mangle accented characters — if your subtitles come out with question marks where the é was, that is the encoding, not the format.

WebVTT was designed for the web, and it is the format the HTML5 track element requires. The file starts with the literal word WEBVTT, and timecodes use a dot before the milliseconds — 00:01:23.400. That comma-versus-dot difference is the whole conversion, most of the time.

What it adds beyond SRT:

• Cue settings: position, alignment and line placement, so a caption can avoid covering a lower-third graphic.
• Styling, via CSS and cue classes, which is how a site gives its captions its own type and background.
• Voice tags, written as a speaker name in angle brackets at the start of a cue, so a player can distinguish or style speakers.
• Chapters and metadata tracks, which is how a web player builds a chapter list from a file rather than from a description.

If none of those matter to you, VTT is SRT with a header and different punctuation.

Required VTT: the HTML5 track element. A browser will not load an SRT there, and this catches people out constantly — the video plays, the captions silently do not appear, and there is no error to find.

Required SRT, in practice: most editing software's import dialogs, and several social platforms' upload forms that reject anything else. YouTube accepts both, and also its own SBV format nobody needs.

Broadcast and cinema use neither — they use TTML, IMSC or EBU-STL, and if someone has asked you for one of those, they will also have given you a spec to meet.

Everything on this site produces both: the transcription tool's SRT and VTT downloads are the same cues, written to each format's rules, with speaker names carried into VTT as voice tags.

Cue length. Two lines, around 42 characters a line, is the convention every broadcaster converged on because it is what a viewer can read in the time a cue is on screen. A single cue holding a whole sentence of dialogue is the most common amateur mistake.

Reading speed. Under about 17 characters per second for general audiences. A cue that is technically correct and on screen for 0.8 seconds has not been read by anyone.

Sentence-aware splitting. Break cues at clause boundaries, not wherever the character count runs out. "We decided to / cancel the launch" reads worse than "We decided / to cancel the launch", and both read worse than one cue holding the clause.

Names and terms. Automatic transcription gets proper nouns wrong more often than anything else, and a misspelled brand name in a subtitle is the error viewers write in about. Check those before you publish; ignore the rest.

An SRT that is 95% right takes a few minutes to fix. Typing one from scratch takes about an hour per ten minutes of footage, which is the real argument for starting from a machine transcript and editing it.

SRT to VTT, by hand, is three edits: add a WEBVTT line at the top, replace the commas in timecodes with dots, and delete the cue numbers if you like — VTT allows them but does not need them.

VTT to SRT loses anything SRT cannot express: positioning, styling, voice tags. That loss is usually fine, because a player that needed those was a web player and you would have kept the VTT for it.

Do not convert by renaming the file. A .vtt extension on SRT content fails in exactly the confusing way described above: silent, with no captions and no error.