SRT vs VTT vs ASS: Which Subtitle Format to Use

You export a caption file, upload it, and the platform does something you did not ask for. The text lands in the middle of the frame. Your font is gone. Or, worst of all, the viewer sees {\pos(960,200)} printed on screen as though it were dialogue. None of that is a bug — each format was designed for a different delivery situation, and each one discards whatever it was not built to carry.

SubRip, WebVTT and Advanced SubStation Alpha are not three quality tiers of the same file. They are three different answers to a single question: who decides how the text looks — the file, the player, or the renderer? This guide covers what each format can express, what disappears when you convert between them, and how to choose one by working backwards from the destination.

The One Thing the Formats Disagree About

Every subtitle file contains the same two pieces of information: a span of time, and some text to show during it. That much is universal, and it is why a badly chosen format still mostly works. The disagreement starts at the third piece of information — everything about presentation.

SubRip takes the position that presentation is none of its business. It carries no styling at all, which means it cannot be wrong on any device, and also means it cannot be right when you need something specific.

WebVTT was written for HTML5 video, so it assumes there is a web page around the video with a stylesheet in it. It carries placement and hooks for CSS, and leaves the actual colours and fonts to the page.

Advanced SubStation Alpha assumes the opposite: that the file itself is the design document, with fonts, colours, outlines, margins and animation timing all declared inside it. That is enormously capable and almost entirely unportable.

SRT: Timings and Text, Nothing Else

An SRT file is a numbered list of cues in plain text. Each cue is an index, a start and end timecode written as HH:MM:SS,mmm with a comma before the milliseconds, and one or two lines of text.

1
00:00:01,500 --> 00:00:04,200
The comma before the milliseconds is not optional.
A second line is allowed.

2
00:00:05,000 --> 00:00:07,000
<i>Italics are the only styling that travels.</i>

Its simplicity is the whole point. A file that carries no styling instructions cannot give a player instructions it fails to understand, so SRT is the format that always renders. The player applies its own defaults, and on most platforms those defaults are whatever the viewer chose in their accessibility settings — which is frequently the outcome you want anyway.

The cost is that placement is out of your hands. If your video has a lower third at the bottom of the frame and the player renders captions there too, the two overlap and both become unreadable. There is no SRT-side fix for this. The fix is in the edit: move the graphic, or leave the bottom fifth of the frame clear. That constraint is worth designing around from the start, and the reasoning behind reserving frame space is the same reasoning behind keeping text out of the platform's interface zones.

Reach for SRT when the destination is a platform you do not control, when you are handing files to someone else's pipeline, or when the video will be re-encoded by a system whose styling behaviour you cannot test in advance.

WebVTT: The Same File, With an Opinion About Placement

WebVTT is close enough to SRT that the two are often mistaken for each other. The differences are small and strict: the file must open with the word WEBVTT, the milliseconds separator is a full stop rather than a comma, and the cue index is optional.

WEBVTT

00:00:01.500 --> 00:00:04.200 line:10% align:center
This cue sits near the top of the frame.

00:00:05.000 --> 00:00:07.000 position:20% size:60%
This one is constrained to the left.

What you gain is the settings tacked onto the end of the timecode line. line controls vertical placement, align controls horizontal alignment within the cue box, and size controls how wide that box is allowed to be. Those four settings solve the collision problem that SRT cannot: when a graphic occupies the bottom of the frame for twelve seconds, you move the cues covering that span to the top and leave the rest alone.

VTT also supports styling by reference rather than by value. You can tag a span as <c.speaker-two> and then style ::cue(.speaker-two) from the stylesheet of the page hosting the video. This is a genuinely good design for a website you own, and completely inert anywhere else — the class name travels, the stylesheet does not.

That is the practical catch. Upload a carefully positioned VTT file to a large video platform and the text and timings arrive intact while the cue settings are usually dropped, because the platform is rendering captions in its own player with its own accessibility controls. The file is not being rejected; its opinions are simply being overruled.

ASS: Typesetting, at the Cost of Portability

Advanced SubStation Alpha came out of fan-subtitling communities that needed to place translated text alongside signs, labels and on-screen writing, matching the perspective of the shot. The format reflects that: it is a small typesetting language, not a caption list.

[Script Info]
ScriptType: v4.00+
PlayResX: 1080
PlayResY: 1920

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, OutlineColour, Outline, Shadow, MarginV
Style: Body,Inter,64,&H00FFFFFF,&H00000000,4,0,220

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:01.50,0:00:04.20,Body,,0,0,0,,{\pos(540,1500)}Placed to the pixel.

A [V4+ Styles] block defines reusable named styles — typeface, size, fill and outline colour, outline width, shadow, and the margins that keep text off the frame edge. The [Events] block then applies a style per line and can override any part of it inline: absolute coordinates with \pos, movement with \move, rotation on three axes, and per-syllable timing with \k, which is how karaoke and word-highlight effects are expressed.

Because PlayResX and PlayResY declare the resolution the design was authored against, a renderer can scale the whole layout correctly for a different output size. That is why ASS is the natural intermediate format for styled captions even when nobody will ever see the file: the design survives a resolution change intact, which a pixel-baked overlay does not.

Its weakness is the same as its strength. Web players do not render ASS. Feed one to a platform expecting a sidecar file and you get either a rejection or, in the worst case, the override tags printed on screen as literal text. ASS belongs upstream of a renderer, not downstream at a viewer. In practice that means one thing: you use it when the captions are going to be rendered into the picture rather than delivered alongside it.

What Each Conversion Deletes

Conversion between these formats is not symmetric, and the asymmetry is where work gets lost. Going toward a richer format is safe because there is somewhere to put everything. Going toward a simpler one is a deletion, and almost no tool tells you what it removed.

Two of these bite regularly. A VTT file that has been round-tripped through SRT by an intermediate tool comes back with every cue at the player's default position, which looks like the positioning was never applied. And an ASS file converted for a platform upload arrives as unstyled text, which is usually discovered after publishing rather than before.

Choosing From the Destination Backwards

The format is a property of where the file is going, not of how sophisticated your caption work is. Work in this order.

None of this substitutes for getting the timings right first. A perfectly placed cue that stays on screen for four hundred milliseconds is still unreadable, and the numbers that govern that are covered in the reading-speed and duration limits for subtitles. Styling decisions have their own constraints, which apply regardless of which of the three formats carries them — contrast against unpredictable footage is the one that catches people out most often.

Next Steps

Take a video you have already published with captions and check what actually rendered, not what you exported. Play it on a phone, with the platform's default caption settings rather than yours, and look for two things: whether the text sits where you intended, and whether anything on screen is covered.

If the answer is wrong and you delivered SRT, the fix is in the edit, not the file. If you delivered VTT and the placement was ignored, the platform overruled you and SRT would have produced the same result with less work. Either way, record what that platform actually does with subtitle files, because it will not change between projects. The rest of the caption pipeline — timing, styling, and delivery choices — is covered across captions and subtitles.