No account. No daily cap.Others give you three files a day and call it unlimited. Files up to 60 minutes here, as often as you like.
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.
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.
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.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.Across all of these, SRT is the format nobody rejects. If a platform only documents support for one format, it's SRT; VTT only becomes mandatory the moment you're writing your own <video> tag.
For a short file you don't need a converter at all:
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.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.
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..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.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 transcription accuracy.
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.
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.
CapCut and Vimeo both accept SRT for captions (Vimeo also takes VTT); Plex reads either as an external subtitle file sharing the video's filename. SRT is the safest default across all three.
The two most common causes are a UTF-8 BOM at the start of the file (some Windows editors add it invisibly) and the wrong encoding on accented characters. Re-saving the file as plain UTF-8 without a BOM fixes almost every case.
No — a cue that starts before the previous one has ended is invalid. Most editors keep cues in order automatically, but check for overlaps if you've hand-edited timecodes.