← All guides

Subtitle formats: SRT, VTT, ASS, and how they differ

8 min read

Subtitles look like a solved problem until you need one file to work in two places. A caption track that displays perfectly in one player shows raw markup in another, or drifts out of sync, or loses its positioning entirely. The reason is that "subtitle file" covers several formats with genuinely different capabilities.

SRT — the universal one

SubRip Text is the oldest of the common formats and by far the most widely supported. Its structure is almost aggressively simple: a sequence number, a timing line, the text, a blank line, repeat.

1
00:00:04,120 --> 00:00:07,480
The kettle had been boiling for some time.

2
00:00:08,000 --> 00:00:10,900
Nobody, it seemed, was going to attend to it.

That is the entire specification in practice. Timestamps use a comma before the milliseconds, which is the detail that most often breaks naive converters.

SRT has no native styling, no positioning, and no formatting beyond basic italic or bold tags that some players honour and others display literally. This poverty is exactly why it works everywhere: there is almost nothing to implement, so nearly every player, editor and platform accepts it. If you need one format that will not cause an argument, this is it.

VTT — the web one

WebVTT was designed for HTML5 video and is the format browsers expect for the <track> element. It is closely related to SRT, with a few meaningful differences.

WEBVTT

00:00:04.120 --> 00:00:07.480 line:90% align:center
The kettle had been boiling for some time.

Note three things. The file must begin with the WEBVTT header. Timestamps use a period before milliseconds, not a comma. And each cue can carry positioning and alignment settings, so text can be placed deliberately rather than always sitting centred at the bottom.

VTT also supports CSS styling, named cues, and metadata tracks used for things like chapter markers. If subtitles will be played in a browser, this is the right choice; outside the browser, support is good but less universal than SRT.

ASS — the typesetting one

Advanced SubStation Alpha is a different proposition altogether. It supports full typesetting: fonts, sizes, colours, outlines, shadows, precise positioning, rotation, animation and karaoke timing. It emerged from anime fansubbing, where translating on-screen signage and styling dialogue per speaker mattered.

An ASS file has a proper structure — script info, style definitions, then events referencing those styles — and is considerably more complex than either format above. That power comes with a compatibility cost: support outside desktop players such as VLC and MPV is limited, and most web players and platforms will either ignore the styling or reject the file.

Use it when the presentation genuinely matters and you control the playback environment. Avoid it when the file has to travel.

The others you'll meet

SBV is a simple format used by some upload tools — SRT-like, easily converted. TTML and its broadcast profile DFXP are XML-based, used in professional and broadcast workflows, verbose and rarely edited by hand. SCC encodes broadcast closed captions and is genuinely difficult to work with outside specialist tools. LRC is for song lyrics rather than video.

Converting without breaking things

SRT to VTT is nearly trivial: add the WEBVTT header, change comma decimal separators to periods, and drop the sequence numbers (VTT allows cue identifiers but does not require them). Almost nothing is lost.

VTT to SRT loses positioning and styling, because SRT cannot express them. The timing and text survive intact, which is usually what matters.

ASS to SRT loses a great deal — every style, position and effect. The result is readable dialogue with none of the presentation. Converting the other way does not recover it; there is no information to recover from.

The general rule is that converting toward simpler formats always works and always discards, while converting toward richer formats works but adds nothing. Keep the richest version you have as the master, and generate simpler ones from it as needed.

Sync problems and how to fix them

Two distinct failures look similar. A constant offset — the whole track early or late by a fixed amount — is the easy case: most players offer a subtitle delay control, and any subtitle editor can shift every timestamp at once.

Progressive drift, where subtitles start correct and gradually slide, means a frame-rate mismatch. A track timed against 23.976 fps played against 25 fps will drift steadily. This needs rescaling rather than shifting — multiplying every timestamp rather than adding to it — and most subtitle editors have a function for exactly this.

Embedded versus separate

Subtitles can live in their own file next to the video, or be muxed into the container itself. Separate files are easy to edit, easy to swap, and easy to lose — a video copied to another device without its .srt silently becomes a video with no subtitles.

Embedded tracks travel with the file and can include several languages at once, at the cost of needing a tool to change them. MKV handles multiple subtitle tracks best; MP4 supports them with more restrictions.

If a file is going to be copied around, embed. If it is going to be edited or corrected, keep it separate. For anything that must simply work on an unknown device, an SRT with exactly the same filename as the video is still the most reliable arrangement in existence.