SRT file vs VTT which subtitle format do you need?

Here's exactly how SRT and WebVTT differ, with real examples, and which one each platform actually wants.

Why this even comes up

Every transcription run through ScribeGrab already produces both SRT and VTT automatically, so in principle nobody here has to choose between them. The question "so which one do I actually need" still gets asked constantly, and the error log shows the other half of why: "That video has no subtitles, so we'd have to…" was hit 49 times in the 40 days to 21 August 2026, almost always someone expecting an existing subtitle file to simply be pulled off a video that never had one. There's no file to convert or compare formats on in that case — it has to be generated from the audio first, which turns a five-second format question into an actual transcription job. Across every tool here, 1,647 jobs ran in that same window, and the subtitle ones came back as SRT and VTT together every time, which is the short version of the answer below.

The 30-second answer

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.

What the formats actually look like

SRT example

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.

VTT example

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.

The differences that matter

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.

Which platforms want which format

• YouTube: accepts both SRT and VTT (and more) for caption uploads. Either works; SRT is the conventional choice.
• Premiere Pro, DaVinci Resolve, Final Cut Pro: import SRT straight onto a caption track. Desktop editors are firmly SRT territory.
• Your own website (HTML5 video): browsers only accept VTT in the <track> element. SRT will silently fail.
• VLC and most media players: happily play a matching .srt file placed next to the video; most also handle VTT.
• LinkedIn, Vimeo, most social platforms: SRT is the common denominator for caption uploads.

Vimeo also accepts both SRT and VTT (WebVTT) in its caption uploader, same as YouTube. CapCut imports SRT onto its caption track, and its own auto-caption export is also SRT — handy if you're moving captions between CapCut and another editor. Plex looks for a subtitle file with the same name as the video in the same folder (movie.mp4 next to movie.srt or movie.en.srt) and reads either SRT or VTT as an external "sidecar" file, though SRT remains the more common choice in Plex libraries. DaVinci Resolve imports SRT directly onto a subtitle track and can export your edited captions back out as SRT too. Across all of these, SRT is the format nobody rejects: if a platform only documents support for one format, it's SRT, and VTT only becomes mandatory the moment you're writing your own <video> tag.

Converting SRT to VTT (or back) by hand

For a short file you don't need a converter at all:

1. SRT → VTT: add a line reading WEBVTT plus one blank line at the very top of the file, then find-and-replace every comma in a timecode (00:00:01,000) with a period (00:00:01.000). Cue numbers can stay; VTT simply ignores them.
2. VTT → SRT: delete the WEBVTT header line, replace every timecode period with a comma, strip any cue settings after the timecode (line:85% align:center and similar), and number the cues in order starting from 1 if they aren't already.

That's the entire conversion: same text, same timing, two characters different per line. It's mechanical enough that almost every subtitle tool does it automatically — including ScribeGrab, which just hands you both files from one upload so there's nothing to convert.

Going the other way — converting VTT to SRT for an editor that only imports SRT — is the same trade in reverse: drop the header, swap the periods back to commas, and you're done.

Common mistakes that break a subtitle file

• A UTF-8 BOM at the start of the file. Some editors (Notepad on Windows especially) save a few invisible bytes before the text. In an SRT this can push the first cue's number onto a line the parser doesn't recognise; in a VTT it can stop WEBVTT from being read as the required first line at all. Re-saving as "UTF-8" without a BOM in any modern text editor fixes it.
• Wrong encoding on non-English text. An old SRT saved as ANSI/Windows-1252 shows accented letters (é, ñ, ü) as garbled characters in players that expect UTF-8. VTT requires UTF-8 outright, so this mostly bites SRT files carried over from older software.
• Overlapping or out-of-order timecodes. A cue that starts before the previous one ends is technically invalid: some players silently show both at once, stricter parsers reject the whole file. Keep cues in ascending, non-overlapping order.
• The wrong file extension. Renaming a VTT file to .srt (or the reverse) doesn't convert it — the header and timecode format inside still don't match what the extension promises, and the platform will either reject it or render it wrong.

Using VTT on the web

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.

So which should you generate?

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 10 recordings a day. 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 transcription accuracy.

Generate SRT + VTT free →

A PDF breaks in its own small technical ways — truncated mid-download, a damaged internal structure — and won't open at all rather than just showing garbled characters. ScanReviver's repair PDF rebuilds one that a viewer refuses to open.

By Sam Ridder — I build and run ScribeGrab on my own hardware, on my own. Who I am.

FAQ