SRT vs VTT vs SBV: subtitle formats

SubRip files came out of a Windows program of the same name that ripped subtitles off DVDs, and they never had a formal specification. The format is simply what that program wrote and what every player since has learned to read. A cue is four things stacked on separate lines: a number, a timing line, one or more lines of text, and a blank line that ends the block.

The timing line is the part worth memorising: two stamps of hours, minutes, seconds and milliseconds separated by an arrow, with a comma before the milliseconds. Hours are always written out, milliseconds are always three digits. Because there is no specification, real files break these rules constantly — indices that restart halfway through, missing blank lines, arrows with extra dashes — and a parser that wants to be useful has to accept all of it anyway.

Formatting is limited to a handful of HTML-like tags that most players honour: italic, bold, underline and a font tag for colour. Position is not part of the format at all, so the text lands wherever the player decides to put it, which is almost always centred along the bottom of the picture.

WebVTT is SRT cleaned up and specified, written for the track element of HTML5 video. A file starts with the word WEBVTT on its first line, and that header is how a browser knows what it is reading. Timestamps use a dot instead of a comma, and the hours field may be left out entirely, so a stamp like 01:23.456 is perfectly legal.

The interesting additions come after the timestamps. Cue settings such as line, position, size and align tell the player where to put the text, so a caption can step out of the way of burned-in credits. A cue may also carry an identifier on the line above its timing, and the file can hold NOTE blocks for comments, STYLE blocks containing real CSS, and REGION blocks that define scrolling caption areas.

Two practical consequences follow. WebVTT must be UTF-8 — the specification says so and browsers enforce it — and it is the only format an HTML5 track element will load. If the subtitles are going on a web page, converting to VTT is not optional.

SBV is YouTube's old caption format and the simplest of the lot: a timing line with the two stamps separated by a comma, then the text, then a blank line. No numbering, no styling, single-digit hours. You still meet it whenever someone exports captions from an older YouTube workflow.

ASS — Advanced SubStation Alpha — comes from the fansubbing world and is a different animal: an INI-like file with Script Info, Styles and Events sections, where every line of dialogue names a style and can carry override tags in braces. {\an8} moves a line to the top of the screen, a pos tag pins it to an exact pixel, and karaoke tags drive syllable-by-syllable highlighting. Its timestamps are hundredths of a second rather than milliseconds.

Broadcasters and streaming services use XML instead. TTML and its DFXP profile are what studios exchange; older American captioning uses SCC, which stores line-21 caption bytes against drop-frame timecode. You rarely edit these by hand, but their existence explains why a file that came from a studio will not simply open in a desktop player.

SRT and WebVTT both store milliseconds, ASS stores hundredths of a second, and SCC stores whole frames. A millisecond is far finer than anyone can perceive — at 25 fps a single frame lasts 40 ms — so raw precision is never the problem. What matters is whether a format thinks in time or in frames, because frame-based files are the ones that break when the video's frame rate changes.

Overlapping cues are treated differently everywhere. A well-formed SRT never overlaps; when it does, VLC and mpv stack both lines while some hardware players silently drop one of them. WebVTT is explicit about the case: overlapping cues are legal and the rendering algorithm lays them out. If the file is going to an unknown player, trimming the overlaps is the safe choice.

None of the text formats declare their encoding. A .srt is a stream of bytes and the player guesses, which is exactly why the same file can look perfect in VLC and like nonsense on a television. Russian, Ukrainian and Bulgarian files written by older tools are usually Windows-1251, Western European ones Windows-1252, and anything modern is UTF-8, sometimes with a byte-order mark at the front.

The working rules are short. Save UTF-8 for software players and for the web, keep the byte-order mark only if a specific device demands it, and fall back to Windows-1251 for old hardware that cannot manage anything else. WebVTT sidesteps the whole question by mandating UTF-8, which is one more reason the web settled on it.

SRT to WebVTT is nearly lossless: add the header line, swap the commas for dots, keep the text as it is. Going the other way discards whatever was WebVTT-specific — cue settings, identifiers, STYLE blocks — because SRT has nowhere to put them. Converting ASS to SRT loses considerably more: positions, fonts, colours and karaoke timing all vanish, and the dialogue is what remains.

That is why a converter ought to tell you what it is throwing away. SubShiftly keeps cue settings and identifiers in memory when it opens a VTT, so a VTT to VTT round trip preserves them, and they are dropped only when you deliberately export SubRip.