SRT vs VTT: which one to use

Subtitles 17 September 2026

They carry the same lines, at the same times, and differ in about three characters. The reason to care is that a handful of places accept exactly one of them.

The short answer

Take SRT for video editors, desktop players and uploading captions to YouTube. It is the format everything accepts.
Take VTT when the subtitles are going on a web page, because the HTML5 <track> element reads WebVTT and nothing else.
If you are not sure, take SRT. Wider support, and converting to VTT later is one header line and a find-and-replace.
The real differences: VTT starts with a WEBVTT line, and its timestamps use a full stop before the milliseconds where SRT uses a comma.
VTT can also carry styling and positioning that SRT cannot — which most people never need, and which some players ignore anyway.

The same three cues, in both

SRT

1
00:00:01,200 --> 00:00:04,600
So today we are finally opening the
box everyone has been asking about.

2
00:00:04,600 --> 00:00:07,900
I have not looked inside. Not once,
I promise.

3
00:00:08,300 --> 00:00:11,400
Right — let us do this properly.

VTT

WEBVTT

1
00:00:01.200 --> 00:00:04.600
So today we are finally opening the
box everyone has been asking about.

2
00:00:04.600 --> 00:00:07.900
I have not looked inside. Not once,
I promise.

That is genuinely the whole difference in an ordinary file: the header line, and a full stop where the comma was. Both are plain UTF-8 text, both number their cues, both use --> between the start and end times, and both put the text on the lines underneath.

What actually differs

	SRT (SubRip)	VTT (WebVTT)
File header	None	`WEBVTT` on the first line, required
Millisecond separator	Comma — `00:00:01,200`	Full stop — `00:00:01.200`
Cue numbers	Required	Optional, and can be names rather than numbers
Positioning	Not part of the format	Per-cue position, alignment and size settings
Styling	Basic inline tags, unevenly supported	A CSS-like `STYLE` block and cue classes
Comments and metadata	No	`NOTE` blocks, and chapter and metadata tracks
HTML5 `<track>`	Not supported	The only format it reads
Everything else	Accepted essentially everywhere	Widely accepted, occasionally not

Which to take, by where it is going

Where the subtitles are going	Take	Why
A video editor — Premiere, DaVinci Resolve, Final Cut, CapCut	SRT	The format every editor imports without being asked twice.
A desktop player — VLC, IINA, mpv	SRT	Drop it beside the video with the same filename and it loads itself.
Uploading captions to YouTube	SRT	YouTube takes both, but SRT is the path of least resistance.
An HTML5 `<video>` on a web page	VTT	The `<track>` element reads WebVTT and only WebVTT.
HLS or DASH streaming	VTT	Both specify WebVTT as the subtitle format.
Social video — Instagram, TikTok, LinkedIn	SRT	Where an upload is offered at all, it is almost always SRT.
Not sure yet	SRT	Wider support, and converting later is trivial.

Converting between them

SRT to VTT is two edits: add WEBVTT and a blank line at the top, and change the comma in every timestamp to a full stop. Nothing else has to move.

# SRT → VTT
{ echo -e "WEBVTT\n"; sed 's/,/./g' subtitles.srt; } > subtitles.vtt

That sed is deliberately blunt. It replaces every comma in the file, including commas in the dialogue, which is fine for timestamps and wrong for the text. For anything you are shipping, convert only the timestamp lines — or just export the format you need in the first place, which costs nothing.

VTT to SRT is the same in reverse, plus stripping anything SRT has no room for: NOTE blocks, STYLE blocks, cue settings after the timestamp, and named rather than numbered cues.

Getting a file in either format

If you are here because you need subtitles rather than because you needed to settle a format argument: the media studio takes a video or audio file — MP4, WebM, MP3, M4A or WAV — reads it in the browser, transcribes and translates the speech, and offers the result as either format at the end. The file itself never leaves your computer.

Thirty minutes every week are free, only speech is billed, and both downloads contain the same lines — so the choice at the end is genuinely just the one this page is about. There is a full walkthrough.

Questions

What is the difference between SRT and VTT?

In an ordinary file, two things: a VTT file begins with a WEBVTT line, and its timestamps separate the milliseconds with a full stop where SRT uses a comma. VTT additionally supports cue positioning, styling, comments and metadata, which SRT has no room for.

Which should I use for YouTube?

SRT. YouTube accepts both, but SRT is the format its upload flow is happiest with and the one every other tool in the chain will also take.

Which should I use for a website?

VTT, and there is no choice about it: the HTML5 <track> element reads WebVTT and nothing else. HLS and DASH streaming both specify WebVTT as well.

Can VLC play a VTT file?

Generally yes, but SRT is the safer choice for desktop players. Name the subtitle file the same as the video, put it in the same folder, and it loads automatically.

Is one of them more accurate than the other?

No. They are containers for the same lines with the same timings. Accuracy comes from what generated the subtitles, not from which format you saved them in.

Can a subtitle file hold two languages at once?

Not as two separate tracks, but a single cue can carry both lines. Turn on the option to show the original words under the translation before generating, and each cue is written with the translated line first and the original beneath it in brackets — so any player shows both without needing two files.

What about ASS and SSA?

Those are a different class of format, built for heavy styling, positioning and typesetting — the kind of thing fansubbing uses. They are worth it when the subtitle is doing design work. For a translated transcript with timings, SRT and VTT are the right size of tool.

Get a subtitle file for something you already have

Thirty free minutes every week. No install, and the file stays on your computer.

Open the media studio