txscribe
← Writing

SRT vs VTT: what actually differs, and what you lose converting

·6 min read

Put an SRT file and a VTT file side by side and you'd be forgiven for thinking someone changed the extension and nothing else. Same numbers, same arrows, same lines of text. Most of the time you can convert one to the other and never notice a difference.

Most of the time. The places they differ are small, and they're exactly the places that bite: a video player that shows nothing, a caption that jumps to the top of the screen, a speaker's name that vanishes on the way through a converter. This is the short version of what's different and what to do about it.

The same caption, twice

Here is one caption in SubRip:

1
00:01:04,250 --> 00:01:07,900
We moved the launch because the
numbers weren't ready.

And here it is in WebVTT:

WEBVTT

00:01:04.250 --> 00:01:07.900
We moved the launch because the
numbers weren't ready.

Three differences are visible already.

  1. The header. A WebVTT file must start with the word WEBVTT. SubRip has no header at all.
  2. The decimal separator. SubRip writes milliseconds after a comma (04,250); WebVTT uses a full stop (04.250). It's the most common reason a hand-renamed file fails to load.
  3. The cue number. SubRip numbers every caption. In WebVTT a cue can carry an identifier, but it's optional and doesn't have to be a number.

There's a fourth you can't see here: WebVTT lets you leave the hours off a timestamp (01:04.250), and SubRip, strictly, does not. Files in the wild ignore that rule in both directions, which is why a tolerant reader matters more than a strict one.

Where they really differ

SubRip is a de facto format. It grew out of a piece of ripping software and was never formally specified, so "SRT" means whatever the most popular players happen to accept. Many of them render <i> and <b>, some honour <font color>, and none of that is guaranteed anywhere.

WebVTT is a W3C specification, written for the web, and it has features SubRip simply lacks:

  • Cue settings. After the end time you can write things like line:0 align:start to put a caption at the top of the frame — so it doesn't cover a lower-third or on-screen text.
  • Voice tags. <v Maya>Where were we? marks who is speaking as data, not as part of the text. A player can style or announce it; the words on screen stay clean.
  • Comments and styling. NOTE blocks for humans, STYLE blocks with CSS for players that support them.
  • Inline timestamps, for karaoke-style captions that reveal word by word.

If none of that is in your file, the two formats carry exactly the same information.

Which one to use

Use WebVTT when the captions go on a web page through HTML's own <track> element. Browsers read WebVTT there and not SubRip — an SRT file in a <track> tag simply shows nothing on screen. The only sign of the problem is an error event in the page's code, which nobody watching the video will see. This is the single most common reason to convert.

Use SubRip when you're handing captions to a video editor, a desktop player or a colleague whose tools you don't know. It is the older, more widely accepted of the two, and with no styling to lose it's the safest default.

For the big video platforms it matters less. YouTube, for one, accepts both — but its help pages say it ignores any styling in an SRT file, while in WebVTT it honours positioning and basic bold, italic and underline. If your captions have none of that, upload whichever you have.

What a conversion throws away

Going from SubRip to WebVTT can lose nothing: WebVTT has a place for everything SubRip carries, including italics and bold. Add the header, swap the commas for full stops, drop or keep the numbers.

Going the other way is where information disappears, because SubRip has nowhere to put it:

  • Positioning is gone. A caption moved to the top of the frame with cue settings comes back at the bottom, over whatever you were trying to keep clear.
  • CSS styling is gone — anything set in a STYLE block or through cue classes. Basic italics and bold are a different matter: most players read <i> and <b> in SubRip too, so a converter can carry them across (not every destination will show them — YouTube, for one, ignores styling in SRT).
  • Speaker names have to go somewhere. SubRip has no speaker field, so the convention is to write the name into the caption text — Maya: Where were we? — which costs screen space on every line it appears.
  • Comments and word-by-word timing are dropped.

Apart from the italics and bold, none of that is a converter's fault; it's the difference between the formats. The failure worth worrying about is a converter that drops captions — a block it couldn't parse — and hands you a file that looks complete. Six hundred cues in, five hundred and ninety-six out, and you find out when someone watches the video.

Doing it

We built a small SRT ↔ VTT converter for this, and it tries to be honest about each of the points above:

  • It detects the format from the content, not the file extension, because the extension is usually the thing that's wrong.
  • It keeps a WebVTT voice tag as a speaker name, and reads a leading Name: in SubRip as one, so you can choose whether names appear in the output.
  • It reads files with missing hours, Windows line endings, a byte-order mark and cue settings after the arrow.
  • If a block can't be read, it says how many were left out instead of quietly dropping them.
  • It can shift every caption by a fixed number of seconds, for the file that's consistently half a second late.
  • It runs entirely in your browser. The file is never uploaded.

What it won't do is keep styling. It strips inline markup such as <i> and <b> in both directions — even SubRip to WebVTT, where the format itself could keep it — and it can't carry positioning into SubRip, which has nowhere to put it. If your captions depend on either, don't run them through it.

If you're making the captions from scratch

Subtitles written from a transcript are only as good as the timings underneath them. txscribe times every word, so each caption it exports as SRT or VTT starts on its first word and ends on its last, and a line too long for the screen is split at the end of a clause where there is one, and between two words where there isn't. Speaker names follow the formats' own conventions: a voice tag in WebVTT, and in SubRip a name only where the speaker changes, not stamped on every line of a monologue.

When a line is wrong, you click it, hear that second, and fix it before you export. One honest caveat: a line you've rewritten no longer has per-word timings — they described the words you replaced — so its captions are spaced across that paragraph's span instead. You can try it on one recording without an account.

Judge it on your own recording.

Ours is the only transcript we can vouch for, and it isn't yours. Run something real through it and see where it holds.

Start free