They look nearly identical, they're both plain text, and yet uploading the wrong one still throws errors on some platforms. Here's exactly how SRT and WebVTT differ, with real examples, and which one each platform actually wants.
SRT (SubRip) is the old universal standard: dead simple, supported by almost every video editor, media player and upload platform. VTT (WebVTT, "Web Video Text Tracks") is the official web standard: it's what the HTML5 <track> element requires, and it adds styling and positioning features SRT never had. Rule of thumb: uploading to a platform or importing into an editor → SRT; embedding in your own website → VTT. When in doubt, keep both — ScribeGrab gives you both files from a single upload, so you never have to choose.
1 00:00:01,000 --> 00:00:04,200 Welcome back to the channel. 2 00:00:04,400 --> 00:00:07,900 Today we're testing three budget microphones.
Each cue is: a sequence number, a timecode line with a comma before the milliseconds, one or more lines of text, and a blank line. That's the entire format.
WEBVTT 00:00:01.000 --> 00:00:04.200 Welcome back to the channel. 00:00:04.400 --> 00:00:07.900 line:85% align:center Today we're testing three budget microphones.
Three visible differences: the mandatory WEBVTT header on the first line, a period instead of a comma before the milliseconds, and optional cue settings after the timecode (position, alignment, line placement). Cue numbers are optional in VTT. VTT also supports NOTE comment blocks, STYLE blocks with CSS, and inline tags like <b>, <i> and voice tags (<v Anna>) for speaker labels.
| SRT | VTT | |
|---|---|---|
| Header | None | WEBVTT required on line 1 |
| Millisecond separator | Comma (00:00:01,000) | Period (00:00:01.000) |
| Cue numbers | Required | Optional |
| Styling | Basic tags at best; often stripped | CSS via STYLE blocks, inline tags, per-cue classes |
| Positioning | No | Yes — line, position, align settings |
HTML5 <track> | Not supported by browsers | The required format |
| Encoding | Historically messy (ANSI legacy files) | Always UTF-8 |
The comma-versus-period detail is the classic gotcha: paste SRT timecodes into a VTT file (or vice versa) and strict parsers reject the whole file.
<track> element. SRT will silently fail..srt file placed next to the video; most also handle VTT.This is the one place the choice is made for you. Captions on an HTML5 video look like this:
<video controls src="/talk.mp4">
<track kind="captions" src="/talk.vtt"
srclang="en" label="English" default>
</video>
The browser renders the cues natively, viewers can toggle them, and because the text is real text (not burned into pixels), it's accessible and indexable. For the full walkthrough per platform, see how to add subtitles to any video.
Both, ideally — they carry identical text and timing, so there's no quality trade-off, only compatibility. Every transcription on ScribeGrab produces the TXT transcript plus both SRT and VTT from one upload, free, with no daily cap. Upload your audio or video once and keep whichever file each platform asks for. And if you're wondering how close the automatic transcript will be to what was said, read our honest breakdown of AI transcription accuracy.
SRT is the older, simpler format: numbered cues with comma-separated milliseconds. VTT is the web standard: a WEBVTT header, period-separated milliseconds, optional cue numbers, plus styling and positioning features SRT lacks.
YouTube accepts both, so either works. SRT is the safest all-round choice for upload platforms; VTT is required when embedding captions in your own HTML5 player.
Yes — add a WEBVTT first line and change the comma before milliseconds to a period. Or skip conversion entirely: ScribeGrab outputs both formats with every transcription.
Premiere Pro, DaVinci Resolve and Final Cut Pro all import SRT directly. SRT is the de-facto standard in desktop editing.