SRT vs VTT: the difference, and when it actually matters

Open an SRT file and a VTT file side by side and they look almost identical — numbered blocks, timestamps, text underneath. The difference that actually matters isn't really the format itself. It's where each one is expected.

What each file actually is

Both are plain text, which surprises people who expect a subtitle file to be some kind of media container. You can open either in Notepad or TextEdit and read it. Here is a complete SRT file:

1
00:00:01,000 --> 00:00:03,500
This is the first caption.

2
00:00:03,500 --> 00:00:06,000
And this is the second one.

And the same captions as WebVTT — a header line, periods instead of commas in the timestamps, and no sequence numbers:

WEBVTT

00:00:01.000 --> 00:00:03.500
This is the first caption.

00:00:03.500 --> 00:00:06.000
And this is the second one.

That's genuinely the whole difference at the file level. If you came here wondering what a .vtt file is because one landed in your downloads: it's that, and it's safe to open in a text editor.

What's actually different

WebVTT (.vtt) was built for the web. It's what HTML5 <video> elements expect natively, it uses a period in its timestamps instead of a comma, and it supports things SRT never had — positioning a caption in a specific part of the screen, styling text, tagging who's speaking as a structured cue rather than just typing their name.

SRT (.srt) predates all of that. It came out of a DVD-subtitle-ripping tool in the early 2000s, and its plainness is exactly why it's survived — YouTube, most video editors, and most media players still treat it as the format that just works everywhere, precisely because it doesn't try to do anything clever.

When it actually bites you

Most of the time you can use either one and never notice a difference — anything that reads one format tends to read both. A few situations where it doesn't work out that way:

• A platform with a strict upload requirement — some ad and streaming platforms only accept one format, not both.
• Embedding captions directly in an HTML5 <video> tag via <track> — browsers expect VTT there, not SRT.
• Using cue positioning or styling at all — that's a VTT-only feature. SRT has no equivalent, so it just gets dropped if you convert down to SRT.

So which should you pick?

SRT, unless something in front of you specifically asks for VTT. It's accepted in more places, every editor reads it, and for ordinary captions — words on screen, correctly timed — you lose nothing at all by choosing it.

Pick VTT when captions will play in an HTML5 video element on a page you control, or when you actually need what only VTT offers: moving a caption out from under a subtitle already burned into the picture, styling it, or marking speakers as structured data rather than typed-out names. Those are real needs, but they're narrower than the format's reputation suggests.

Converting between them

Since the difference is mostly structural — a timestamp separator and an optional header line — converting doesn't require re-transcribing anything. It's closer to a find-and-replace than real work. Subtitle Converter does exactly that conversion in your browser, both directions, with nothing uploaded anywhere — it parses the text locally and hands you the other format instantly.

One asymmetry to keep in mind: SRT to VTT is lossless, because SRT has nothing VTT can't represent. VTT to SRT is not — any positioning, styling or structured speaker tagging has no SRT equivalent and is dropped. The text and timings always survive, so if all you have is ordinary captions, both directions are safe. If you don't have a subtitle file yet at all, Subtitle Generator produces timed SRT from a video or audio file directly.