WebVTT is the subtitle format a browser knows how to read. And it's the only one: plug an SRT into an HTML5 video and absolutely nothing happens. Not an error, not a warning, not a subtitle.
Its extension is .vtt and inside it looks a great deal like an SRT. Three things change: it carries a compulsory header, it puts a dot where an SRT puts a comma, and it can express considerably more than an SRT manages to.
What's inside
WEBVTT
1
00:00:04.120 --> 00:00:06.480
Before we get into figures,
let's go over where we stand.
2
00:00:06.600 --> 00:00:09.000 line:90% align:start
What I wasn't expecting
was the second-week drop.
That first line is obliged to say WEBVTT. If it doesn't appear, if a byte-order mark sits in front of it, or if a blank line comes before it, the browser gets rid of the whole file.
From there, the same old blocks. With two differences you can see at a glance: the dot ahead of the milliseconds, and the option of hanging settings off the end of the timing line.
What it adds over an SRT
Position and alignment. line:90% drops the subtitle down, align:start pins it to the left and position:20% shifts it sideways. Handy for not covering a caption already in the picture.
Styling. A STYLE block with genuine CSS at the head of the file, and classes scattered through the text by way of <c.narrator>. Colours, sizes, shadows.
Who's speaking. A <v Marta>Good morning</v> tag is how the voice gets marked. Players able to recognise it may paint it a different colour; the rest walk straight past. On an interview or a meeting, that is the border between a wall of text and something readable.
Notes and regions. NOTE blocks keep comments nobody sees, and REGION marks out areas of the screen with scrolling of their own, like the captions rolling up on a live broadcast.
Cue identifiers. Above the timing line, each block will take a name — intro, question-3 — to point at it from JavaScript.
When you need a VTT
Every time the video plays inside a browser. If your page holds a <video> with its <track>, that file has to be WebVTT:
<video controls>
<source src="meeting.mp4" type="video/mp4" />
<track src="meeting.vtt" kind="subtitles" srclang="en" label="English" default />
</video>
And the same with today's web players (Video.js, Plyr, Shaka) and with HLS streaming, which distributes subtitles as WebVTT segments.
Beyond the browser's door, hardly anyone asks for it: desktop editors, the players everyone has always used and almost every upload form still expect an SRT.
Two things that break and aren't the file's fault
The server is obliged to send it as text/vtt. Delivered as text/plain or as application/octet-stream, some browsers throw it out. That's touched in the server configuration, never in the file.
And it has to come from the same origin, or bring CORS. A .vtt hosted on another domain without the Access-Control-Allow-Origin header never loads, however beautifully the address works when you open it by hand. It's the number one cause of the classic "the video plays, the subtitles don't".
Neither is a problem with the content and neither leaves a visible error on the page. They surface in the network tab of the browser's tools, and only if you know to go and look there.
Converting it
The trip from SRT to VTT is simple: set the header down, put a dot where the comma was, and escape those & and < characters that an SRT holds as text and that WebVTT would mistake for markup. Our SRT to VTT converter settles all three inside your browser, without the file leaving it.
Backwards, whatever an SRT can't say stays outside — the position, the styling, the regions — so the VTT to SRT converter discards it and turns the voice tags into a «Marta:» opening the line, which is how an SRT can show it. Which one to pick for what.
If what you have is the video and not the subtitles
Upload it and we hand back the transcript with its minutes, with every voice separated and named, and with a summary. The VTT falls out of that already assembled and with the voices marked. No account to begin.