SRT vs VTT: the file is decided by whatever opens it next.

A subtitle file is a schedule: every cue says when a line appears, when it disappears, and what the viewer reads. SRT and VTT both carry that schedule, so either one preserves the timing of the track it came from. The differences show up the moment another program tries to read the file.

The short answer

• Going into a video editor, or uploading captions back to a platform? SRT — it is the format editing software and upload dialogs expect by default.
• Playing inside a web page or a browser-based player? VTT — the HTML5 <track> element reads it natively.
• Only the words matter — notes, a search box, an AI prompt? Neither. Take TXT and stop paying for timing you will not use.
• A platform names a required format? Follow the platform. A general recommendation never outranks an explicit upload rule.

They solve the same problem

It helps to separate two things that get conflated: the track and the file. A track is what YouTube stores — the words plus their timings. A file is one serialisation of that track. SRT and VTT are two serialisations of the same data, which is why converting between them never changes the words or the timing.

What changes is how much structure the file can carry. SRT is deliberately plain: a counter, a time range, a line of text. VTT keeps that and adds a place to put web-specific instructions — where a cue sits on screen, how it is aligned, who is speaking, which CSS class it belongs to.

The same caption, written twice

1
00:00:02,500 --> 00:00:05,000
Choose the format that matches your next step.

2
00:00:05,200 --> 00:00:08,000
The words do not change. The wrapper does.

WEBVTT

00:00:02.500 --> 00:00:05.000
Choose the format that matches your next step.

00:00:05.200 --> 00:00:08.000
The words do not change. The wrapper does.

Three differences are visible in those four lines, and they are the ones that actually break files:

• The separator — SRT writes milliseconds after a comma (00:00:02,500); VTT writes them after a period (00:00:02.500). This is the single most common reason a renamed file fails.
• The header — A VTT file must begin with the literal line WEBVTT. An SRT file begins with a cue number. Swap the extensions without swapping the insides and a strict parser rejects the whole file.
• The counter — SRT numbers every cue and expects the numbers to be sequential. In VTT the identifier is optional — the blank line and the arrow are what delimit a cue.

The differences that change your choice

Choose SRT when a program has to import it

SRT has been the interchange format for long enough that support is assumed rather than checked. That is its real advantage: not features, but the absence of surprises. Desktop editors, captioning tools, upload dialogs and hand-editing in a text editor all treat it as the baseline case.

It is also the easier format to inspect. Open an SRT in any text editor and the structure is obvious in a way that a file carrying style blocks and cue settings is not — which matters when you are checking a single line against the video before quoting it.

Choose VTT when a browser plays the captions

VTT was designed for the web, and the clearest proof is that the browser's own caption pipeline reads it and nothing else. If you are shipping a <video> element with a <track kind="captions">, the file has to be VTT — no plugin, no conversion step, no player-specific handling.

The extras are the reason to stay in VTT once you are there. A cue can carry its own placement and alignment instead of being pushed around by CSS on the container; <v Speaker> marks who is talking without inventing a convention in the text line; a STYLE block keeps presentation next to the cues it affects.

Choose TXT when the timing is not the point

There is a third case that gets forced into this comparison and does not belong in it: you do not want a subtitle file at all, you want the words. Pasting a transcript into notes, a document, a spreadsheet or an AI prompt is not a captioning job, and a timed file only adds syntax you have to strip.

Plain text drops the timing entirely: one line per cue, a blank line between them, no cue numbers, no arrows, no header. That is the version you actually want in notes, in a document or in an AI prompt. And because the same track still produces SRT or VTT on demand, nothing is lost by starting with the text — the only thing you give up is the way back to a moment in the video.

Three ways a subtitle file breaks

1. Renaming the fileChanging .vtt to .srt changes the name and nothing else. The timestamps inside still use the wrong separator and the header is still there (or still missing), so a strict parser rejects the file or drops every cue — and the symptom is usually "the subtitles just do not appear", with no error.What to do: Convert the contents, not the extension. Re-export from the source track, or run a real converter, then open the result and check the first two cues.
2. Losing the WEBVTT lineCopying cues out of a VTT and saving them as a new file is a common way to lose the header. Without WEBVTT on the first line, browsers treat the file as invalid and show nothing, even though every cue below it is perfectly formed.What to do: The first line of a VTT is WEBVTT — always. If you hand-built the file, add it back and retest in the player, not in a text editor.
3. Encoding and blank linesCue text with accents or non-Latin scripts needs UTF-8; a BOM at the start of the file is tolerated by some players and rejected by others. Cues are separated by a blank line, and a missing one merges two cues into a single unreadable block.What to do: Save as UTF-8 without a BOM, keep exactly one empty line between cues, and verify in the program that will actually play the file.

Getting either one from a YouTube video

The format question only becomes real once you have a track to write out. On the subtitle page, every track a video publishes is listed before you download — creator-uploaded and auto-generated are labelled separately, because that label tells you whether the wording was written or guessed.

SRT, VTT and TXT all come out of the same track, so switching format does not change the words or the timing. That also means the useful order is: check the track first, then decide the format — not the other way round.

One limit worth stating plainly: this reads the caption track YouTube already publishes. It does not transcribe audio, so a video with no track produces no file in any format. That is a property of the source, not of the format you picked.