The short answer: if the video plays in a browser, VTT; anywhere else, SRT.
The long one fits into a table and two minutes, and it's worth reading, because half the trouble people have with subtitles comes not from a faulty file but from having picked the wrong format.
The two, side by side
| SRT | VTT | |
|---|---|---|
| Extension | .srt | .vtt |
| Milliseconds | 00:00:04,120 | 00:00:04.120 |
| Header | none | WEBVTT, required |
| HTML5 video | won't read it | the only one it reads |
| Editing suites | all of them | practically none |
| Platform uploads | always gets through | depends on the platform |
| Place on screen | — | yes |
| Styling and colour | — | yes, with CSS |
| Internal comments | — | NOTE blocks |
| Who's speaking | as text and no more | <v Name> tag |
| Time in circulation | since the nineties | since 2010 |
Which one to reach for
VTT if the video will be playing on a web page — an HTML5 <track>, Video.js, Plyr — if HLS is how you serve it, or if the subtitle has to sit somewhere particular on screen so that it covers nothing.
SRT if the file is headed for Premiere, for DaVinci, for Final Cut or for VLC; if some platform's subtitle box is asking for it; if you're passing it to somebody with no idea what they'll do with it; or if reading it is the whole point.
And that last one is the key to the whole thing: SRT plays the part of common denominator. It's been circulating for thirty years and there's nothing that turns it away. Without a specific reason to choose the other, this is the one that will never let you down.
What gets lost in the conversion
SRT to VTT loses nothing, because an SRT holds nothing a VTT can't represent. The one thing to handle carefully is escaping the &, < and > characters, which are ordinary text in an SRT and markup in a VTT. An unescaped "Tom & Jerry" can make a meal of the rest of the line.
VTT to SRT does leave things behind, and they're worth bearing in mind:
- Position and alignment. An SRT has nowhere to put them. Withdrawn.
- Styling. Same again: out go the
STYLEblocks and the<c.whatever>classes. - Regions. They simply don't exist in SRT.
- Notes.
NOTEblocks aren't subtitles and can't end up inside the text. - Cue identifiers. The names are thrown out and the blocks renumbered from one, which an SRT takes for granted.
What does arrive whole: the text, the timings down to the millisecond and who's speaking. <v Marta> tags end up as a «Marta:» at the head of the line, because that much an SRT does know how to show.
It's the conversion most often botched out there. A converter that limits itself to swapping dots for commas leaves you a «line:90% align:start» printed on screen and
NOTEblocks sitting between one subtitle and the next.
What about the other formats?
There are two more you'll come across:
ASS/SSA (.ass), out of anime fansubbing. It does everything VTT does and a good deal more: typefaces, karaoke, animation, transforms. The price is that outside its own world hardly anything takes it.
TTML/DFXP (.ttml, .dfxp), the broadcast industry's. XML, heavy, exhaustive, and what some large platforms demand for professional material. You won't be writing it by hand.
For 95% of cases, the decision still lies between the two above.
Converting from one to the other
All three converters work inside your browser: the file travels nowhere, there's no queue and there's no cap on uses.
- SRT to VTT, so the video on your page carries subtitles.
- VTT to SRT, so your editing suite stops protesting.
- SRT to text, for when you're not after subtitles but after reading what was said.
And if you have no subtitle file yet and only the video or the audio, upload it: we give back the transcript with minutes and voices apart, ready to export in whatever format suits you. No account to begin and nothing to install.