The short answer: if the video plays in a browser, VTT. For everything else, SRT.
The long answer fits in one table and two minutes of reading, and it's worth it, because half the trouble people have with subtitles comes from picking the wrong format rather than from a broken file.
The two, side by side
| SRT | VTT | |
|---|---|---|
| Extension | .srt | .vtt |
| Header | none | WEBVTT required |
| Milliseconds | 00:00:04,120 | 00:00:04.120 |
| HTML5 video | won't read it | the only one it reads |
| Video editors | all of them | almost none |
| On-screen position | no | yes |
| Styling and colour | no | yes, with CSS |
| Who's speaking | text only | <v Name> tag |
| Internal comments | no | NOTE blocks |
| Platform uploads | always accepted | depends which |
| Years in circulation | since the nineties | since 2010 |
When to use which
Use VTT if the video plays on a web page — an HTML5 <track>, Video.js, Plyr — if you're serving it over HLS, or if you need to place subtitles somewhere specific so they don't cover something.
Use SRT if you're opening it in Premiere, DaVinci, Final Cut or VLC; if you're uploading it to a platform that asks for subtitles; if you're sending it to someone and you don't know what they'll do with it; or if you want to read it.
That last one is the real point: SRT is the lowest common denominator. It's been around for thirty years and everything takes it. Without a specific reason to use the other, this is the one that won't cause you trouble.
What you lose in the conversion
SRT to VTT loses nothing: there's nothing in an SRT a VTT can't represent. The only thing to get right is escaping the &, < and > characters that are plain text in SRT and markup in VTT. An unescaped "Tom & Jerry" can eat the rest of the line.
VTT to SRT does lose things, and it's worth knowing which:
- Position and alignment. An SRT has nowhere to put them. Dropped.
- Styling. Same story:
STYLEblocks and<c.something>classes go. - Regions. They don't exist in SRT.
- Notes.
NOTEblocks aren't subtitles and must not end up inside the text. - Cue identifiers. They're dropped and the blocks renumbered from one, which is what an SRT expects.
What you don't lose: the text, the timings to the millisecond, and who's speaking. <v Marta> tags become a «Marta:» in front of the line, because an SRT can show that.
It's the conversion most often done badly. A converter that only swaps dots for commas leaves «line:90% align:start» printed on screen and
NOTEblocks sitting among the subtitles.
What about the other formats?
There are two more you'll run into:
ASS/SSA (.ass), from anime fansubbing. It does everything VTT does and more: typefaces, karaoke, animation, transforms. In exchange, almost nothing outside that world accepts it.
TTML/DFXP (.ttml, .dfxp), the broadcast one. XML, heavy, very complete, and what some large platforms ask for on professional material. You are not going to hand-write it.
For 95% of cases, the decision is still between the two above.
Converting between them
Both converters run inside your browser: the file isn't uploaded anywhere, there's no queue and there's no usage limit.
- SRT to VTT, so the video on your site has subtitles.
- VTT to SRT, so your video editor stops complaining.
- SRT to text, for when what you want isn't subtitles but to read what was said.
And if you don't have a subtitle file yet — only the video or the audio — upload it and you'll get a transcript with timestamps and speakers, ready to export in whichever format you need. First 45 seconds free, no account.