SRT vs VTT — which subtitle format do you need?

Two formats cover almost every subtitle need, they are nearly identical, and picking the wrong one usually means a file that silently does not load. Here is how to choose in ten seconds and why the difference exists at all.

The ten-second answer

• Putting a file next to a video for VLC, a media player, a TV, or a video editor — use SRT.
• Using it with an HTML5 <video> element or a web player — use VTT.
• Uploading to YouTube, Vimeo or LinkedIn — either; SRT is the safer default.

If you genuinely do not know, take SRT. It is the more universally accepted of the two, and converting to VTT later is trivial.

What they actually look like

SubRip (.srt) — dates from a DVD-ripping tool in the late 1990s and became the standard by being simple enough that everybody implemented it:

1
00:00:00,000 --> 00:00:02,500
And so, my fellow Americans,

2
00:00:02,500 --> 00:00:06,120
ask not what your country can do for you.

A number, a time range, the text, a blank line. That is the whole specification.

WebVTT (.vtt) — the W3C’s format for the web, designed alongside HTML5 video:

WEBVTT

00:00:00.000 --> 00:00:02.500
And so, my fellow Americans,

00:00:02.500 --> 00:00:06.120
ask not what your country can do for you.

Three differences, and only three that matter in practice:

1. VTT starts with the literal line WEBVTT. Without it, browsers reject the file outright.
2. VTT separates seconds from milliseconds with a full stop; SRT uses a comma.
3. VTT does not require cue numbers (they are optional and ignored).

That is it. Everything else — the cue structure, the arrow, the blank-line separator — is the same. Which is why converting between them is mechanical, and why this tool simply writes whichever you pick from the same transcript.

Why the comma exists at all

It is a fossil of European decimal notation: SubRip came out of a world where 2,5 meant two and a half. WebVTT standardised on the full stop because that is what the rest of the web uses. There is no technical reason for the difference and no way to reconcile it — a player expecting one and given the other will usually fail to parse the timestamps and show nothing, which is the most common reason a subtitle file “does not work”.

What each format can do that the other cannot

For ordinary subtitles: nothing that will affect you. But if you need it:

VTT can do more. Positioning cues on screen, styling with CSS, regions, chapter tracks and metadata tracks are all in the spec, and browsers implement much of it. If you want captions positioned to avoid on-screen text, VTT is the only one of the two that can express it.

SRT is more universally accepted. Some basic formatting (<i>, <b>, <u>) works in most players by convention rather than by specification. Beyond that it does one thing.

For anything more elaborate — karaoke timing, complex typesetting — people use ASS/SSA, which is a different world and not something a transcription tool should be generating.

Where each one goes

SRT works with: VLC, IINA, MPV, most smart TVs and set-top boxes, Plex and Jellyfin, Premiere Pro, DaVinci Resolve, Final Cut, CapCut, Shotcut, Handbrake, and every major video platform’s subtitle upload.

VTT works with: the HTML5 <video> element via <track>, Video.js, Plyr, JW Player, HLS and DASH streaming manifests, and most platforms as well.

The classic mistake is putting an SRT into a <track src="…"> on a web page. Browsers accept only WebVTT there. It fails silently — no error, no captions button, nothing.

Making a player find your file automatically

For SRT with a desktop player, name the subtitle file exactly like the video with the extension swapped, in the same folder:

board-meeting.mp4
board-meeting.srt

VLC, IINA and most TVs pick it up with no configuration. For a second language, append a language code: board-meeting.en.srt, board-meeting.es.srt.

For the web, point a track element at the VTT and mark the language:

<video controls src="talk.mp4">
  <track kind="subtitles" src="talk.vtt" srclang="en" label="English" default />
</video>

The part that matters more than the format

A valid file is not the same as a usable one, and most automatically generated subtitles fail on readability rather than syntax. The conventions everybody borrows from broadcast practice:

• Roughly 42 characters per line, two lines maximum. Longer lines force the eye to travel too far and cover too much of the picture.
• Break at a sensible point. Split after punctuation or between grammatical phrases, not between an article and its noun.
• Keep each cue on screen long enough to read — a rough rule is 20 characters per second of reading speed, and never less than about a second regardless.
• One thought per cue. A cue holding thirty seconds of speech is technically valid and practically unusable.

This tool applies all of these when it writes the file: over-long segments are split, preferring a sentence boundary, with the timing distributed across the pieces; each cue is then wrapped to two lines at word boundaries. That is the difference between subtitles and a transcript with timecodes stapled to it.

Before you publish

Automatic subtitles need a read-through, and the things to fix are predictable:

• Names. Every one. They are the most-noticed error and the most likely to be wrong.
• Speaker changes. If two people alternate, label them — the labels are written into the cues.
• Numbers. Prices, dates, versions.
• Anything over music, where the model may have invented text.

None of that takes long with the audio in front of you, and it is the difference between subtitles that help and subtitles that get complaints. If you want the fuller editing workflow, see cleaning up a machine transcript.