SRT vs VTT: what's the difference?

Both formats do the same core job: pair lines of text with start and end timecodes so a player shows the right caption at the right moment. The difference is lineage. SubRip's SRT is the older, plainer format – Matroska's technical reference calls it perhaps the most basic of all subtitle formats. WebVTT is the web-native one, published by the W3C Timed Text Working Group on the Recommendation track. No standards body governs SRT; it grew as a de-facto convention, which is why its rules stay loose.

You can tell them apart at a glance. A WebVTT file must open with the literal string WEBVTT on its first line, after an optional byte-order mark. An SRT file has no header at all. It starts straight into the first cue, numbered with a sequential index. That index above every SRT block is required; WebVTT makes the cue identifier optional.

The most cited difference is a single punctuation mark. SRT writes its milliseconds after a comma – the Matroska reference shows a cue running 00:02:17,440 --> 00:02:20,375. WebVTT writes the same field after a full stop, as in 00:02:17.440. The WebVTT grammar is explicit: a timestamp ends with a full stop followed by three ASCII digits for the thousandths of a second. Both formats use HH:MM:SS and a three-digit fraction; only the separator changes.

That one character is why the two files aren't interchangeable by a rename. A valid WebVTT file also needs its WEBVTT header, which an SRT file never carries. A converter has to add that header and swap every comma for a full stop. If you're building a caption file by hand, start from the plainer SRT structure and adjust from there.

WebVTT carries formatting that SRT has no mechanism for. The spec defines six cue settings – vertical, line, position, size, alignment, and region – that place a caption anywhere in the frame. SRT has none of these. Matroska notes there are no general settings for SRT at all, so the format leaves that container field blank.

Styling goes further in WebVTT. CSS style sheets can target cues through the ::cue pseudo-element, and a file can hold STYLE blocks for reusable rules and REGION definitions for scrollable caption areas. SRT expresses none of that in the format. Its plainness is the point: if you need a caption parked in a specific corner or styled to match a brand, that lives in WebVTT.

Your player decides the format more than your preference does. The HTML5 <track> element is defined to read WebVTT: MDN states the tracks are formatted in WebVTT format (.vtt files), and the WHATWG HTML standard ties the track element's URL to a WebVTT resource. The <track> element is specified only for WebVTT; SRT is not a defined <track> format.

WebVTT also carries more than captions. Through the <track> kind attribute, it can hold chapters, metadata, and descriptions. The WebVTT spec lists captions, subtitles, chapters, audio descriptions, and metadata as data kinds a file can carry. SRT defines no such mechanism. If your target is a web page, export a WebVTT file and point a <track> at it.

SRT's reach comes from its plainness. As the most basic subtitle format, it's the low-common-denominator file that most desktop players and upload fields accept. That makes it a sensible default when you don't know what the far end supports. Exporting from a recording for those uploads? Generate an SRT instead.

With the format settled, the next step is producing the file. Upload your recording and export it in the format you picked. From there, the file has to reach your player, and how you deliver it depends on where it's going.

On a web page, you host the .vtt and point an HTML5 <track> at it. A desktop player is different: side-load the .srt next to the video so the player finds it, or embed it in the file. Social platforms take the caption file in an upload field on the post. Getting the captions to display is its own step, separate from choosing the format, but the file you just exported decides how it runs.