SRT vs WebVTT vs ASS: subtitle formats compared

Three subtitle formats dominate everyday caption work, and they are not interchangeable files with different extensions: they are three different ideas about what a subtitle is. SRT treats a subtitle as numbered lines of plain text with timestamps — nothing else. WebVTT treats it as a web document, with styling, positioning and metadata built into the specification. ASS treats it as typesetting, where how the words look — font, colour, placement, even letters highlighted one syllable at a time — is part of the content. Choosing well, and knowing what a conversion silently throws away, saves the particular pain of discovering a ruined caption file inside the player. This guide compares the three formats structurally, maps where each one actually plays, and uses the subtitle converter and the subtitle checker on this site as the worked example.

SRT: the plain-text minimum

An SRT (SubRip) file is a sequence of numbered blocks: an index number, a timestamp line in the form 00:01:02,500 --> 00:01:05,000 — note the comma before the milliseconds — and one or two lines of text. That is the entire format. There is no header, no styling model, no positioning. A few players honour simple HTML-like tags such as <i> for italics, but that is player generosity, not specification. SRT's poverty is its strength: every editor, player, platform and converter reads it, it can be fixed in any text editor, and there is almost nothing in it that can break. If a file must work somewhere unknown, it should probably be SRT.

WebVTT: the web's caption format

WebVTT (Web Video Text Tracks) is the W3C format designed for the HTML5 <track> element, and it is the only one of the three that browsers play natively. Files begin with a WEBVTT header, timestamps use a dot before milliseconds (00:01:02.500), and beyond plain cues the specification supports cue settings for position, alignment and regions; styling through CSS classes embedded in the file; voice tags that name the speaker; NOTE comment blocks; and separate file kinds for chapters and metadata. In practice, browser support concentrates on the basics — cues, timing, some settings — and elaborate styling is inconsistently applied, so a VTT file authored for the web should still be tested in a real browser rather than trusted on paper.

ASS: typesetting as content

ASS (Advanced Substation Alpha, with its older SSA variant) comes from the fansubbing world, where subtitles routinely do things broadcast captions never attempt: signs and posters translated in place, at an angle; karaoke lyrics highlighted syllable by syllable; several speakers placed in different screen positions with distinct fonts and colours. An ASS file therefore carries a styles section — fonts, sizes, colours, outlines, shadows — plus per-line override tags for position, movement, fades and karaoke timing, and even vector drawings. Editors such as Aegisub exist specifically to author it. The cost is support: ASS renders fully only in desktop players such as mpv and VLC and in specialist tooling. Browsers cannot play it natively, and platforms that accept it generally flatten it to plain text.

Where each format actually plays

• Websites (HTML5 video): WebVTT only, via the <track> element. SRT and ASS need conversion before a browser will touch them.
• YouTube and similar platforms: uploads are accepted in several formats, SRT and WebVTT among them, and YouTube also accepts ASS — but playback uses the platform's own plain caption rendering, so styling, positioning and karaoke do not survive the trip.
• Streaming delivery: platforms typically convert incoming files into their own timed-text pipelines, so the timing and text limits in the subtitle timing guide matter more than the container you choose.
• Desktop players (VLC, mpv, IINA): all three formats play, and ASS plays with its styling intact — the main situation where ASS is the right delivery format rather than only an authoring one.
• Editing and translation workflows: SRT is the safest interchange format because nothing in it can surprise the next tool in the chain; ASS is kept when the styling itself must be handed over.

What conversion loses — stated plainly

Text and timings are the portable core; almost everything else is a property of one format that stays behind. Converting from ASS or WebVTT to SRT removes font styling, colours, positioning and karaoke effects, and WebVTT cue settings, chapters and voice tags have no SRT equivalent to land in. The converter on this site is explicit about its contract: it preserves plain caption text and valid timings, and removes ASS styling, positioning, karaoke and effects as well as VTT cue settings; ASS vector drawings are rejected outright, and an ASS file it produces uses a basic default style that you should verify in your subtitle editor. Two smaller losses surprise people: NOTE comments in WebVTT do not convert, and ruby annotations (furigana) on Japanese text have no home in SRT at all. If any of that layer is the point of the file, do not convert the master — convert a copy, and keep the original as the archive.

How to choose

• Default to SRT when the destination is a platform, a client, or anywhere you do not control the player. Maximum compatibility, minimum surprise.
• Choose WebVTT when the subtitles ship with web video you control: it is the native browser format, and the only one where chapters, speaker labels and modest positioning are even possible in a browser.
• Choose ASS when the styling is the content — karaoke, typeset signs, positioned multi-speaker scenes — and the audience will watch in a desktop player that renders it. Author in ASS, archive in ASS, and export SRT or VTT copies for everywhere else.
• Whatever you choose, run the result through a checker for line length, reading speed and duration before delivery. Format correctness and readability are different checks, and players forgive neither for long.