Convert ASS to VTT

Nothing, if you hand it the ASS. The track element takes WebVTT and only WebVTT, and the refusal is silent — the video plays, the subtitle menu is empty, and there is no console message pointing at the format. This is the whole reason the conversion exists, and it is the same wall that SubRip files hit.

The difference with ASS is what is at stake. A SubRip file had nothing to lose. A typeset track has fonts, colours, positions and possibly effects, all of which were the point, and a browser has no native way to render any of them. Converting is not a formality here; it is a decision about how much of the design you are prepared to rebuild by hand or to give up.

WebVTT is not styling-blind. A cue can carry a line setting that moves it vertically, an align setting that moves it horizontally, a position and a size. That is genuinely more than SubRip offers and it covers the most common typesetting need, which is keeping a caption away from something else on screen.

None of it is filled in. Every ASS line is reduced to a start, an end and plain text before anything is written, so the alignment field of the style, the numeric grid position and any inline positioning override are all gone by the time the WebVTT is composed. Cues arrive with no settings at all, and the browser places every one of them at the bottom centre.

The work is manual and it is worth doing selectively. Open the ASS beside the VTT and find the lines that were positioned — signs, on-screen text, anything that was not dialogue. Those are the cues that will collide with the picture at the bottom of the frame; the dialogue was always going to sit there anyway.

For each one, a line setting expressed as a percentage moves the cue up, and an align setting shifts it left or right. Two words on the timing line, and the caption is out of the way. It will not match a typesetter’s placement over a moving sign, because WebVTT cannot animate and the browser will not let it, but it turns an unreadable overlap into a readable caption.

How many cues that is depends entirely on the source, and it is worth counting before committing to the work. A straightforward dialogue translation has none — every line was always at the bottom and the converted file is finished. A release where signs were typeset scene by scene can have several hundred, at which point positioning each one by hand is a day of work and removing them is ten minutes. Deciding which of those two the file is should happen before the first cue setting is typed.

This is the structural difference between the two formats and the reason nothing can be translated automatically. ASS defines named styles inside the file and each line references one. WebVTT expects the page to style the cue pseudo-element with CSS, and treats the file as content.

Practically that inverts where the work goes. Font, size, colour, text shadow and background are set once in the stylesheet and apply to the whole track, which is less expressive than a per-line override and considerably easier to keep consistent. A class attached to a cue lets a subset be styled differently, which is the closest thing WebVTT has to a style table and is enough to distinguish two speakers.

Everything in curly braces is removed before the text is written, so a colour change, a fade, a move or a rotation leaves nothing behind — no stray characters, no half-translated markup. That is the correct behaviour, because a browser would draw the tag text on screen if it were left in.

It also means italics do not survive, which surprises people. ASS marks italics with an override tag and WebVTT with an angle-bracket tag, and nothing bridges the two. If the track used italics for internal monologue, song lyrics or a second language, restoring them is a pass over the VTT with the angle-bracket form. Both kinds of line break and the hard space are the only pieces of ASS syntax that are translated rather than dropped.

ASS puts several lines on screen at once by design, on separate layers: dialogue at the bottom, a translated sign over the thing it translates. WebVTT has no layers, and both become ordinary cues occupying the same seconds.

Browsers handle that by stacking them at the bottom of the video, which is defensible and rarely what was intended — the sign that belonged in the top right of the frame now sits above the dialogue for two seconds. Either position it with cue settings, as above, or decide the sign is not needed on the web version and remove those cues. On a heavily typeset release, removing them is often the honest answer.

A WebVTT file must begin with the word WEBVTT on its own first line. It is not documentation and a file without it is rejected before anything else is examined. The output here writes it, followed by a blank line, then the cues.

The timestamps are the other requirement. ASS records hundredths of a second; WebVTT is written with three digits of milliseconds after a full stop, so a line starting at 0:00:01.23 becomes 00:00:01.230 with the hours padded. No precision is invented — the timings are exactly as authored, expressed in a longer form.

The kind attribute on the track element distinguishes the two, and the distinction has consequences beyond markup. Subtitles assume a viewer who can hear and translate the dialogue. Captions assume a viewer who cannot hear, and therefore include the non-speech information: who is speaking off screen, when music starts, what the noise was.

A converted ASS track is almost always subtitles, because that is what it was authored as. Marking it as captions to satisfy an accessibility checklist puts the right word in the markup and does not meet the obligation, and for public sector bodies and a growing number of businesses that obligation is a legal one. If captions are what is needed, the non-speech information has to be written, and no conversion produces it.

ASS marks a forced line break inside a dialogue line with a backslash and a capital N, because the whole line has to fit in one comma-separated field. That is translated rather than stripped: it becomes a real newline in the cue text, and WebVTT treats a newline inside a cue as a break the author asked for. A two-line subtitle stays two lines, in the same place.

It is worth checking what those breaks were for. A typesetter breaks lines against a specific rendering at a specific size, and a browser will render the same text in a different font at a size the viewer may have changed. Breaks chosen to balance two lines under a 1080p picture can produce a stranded word on a phone. Where the source used the soft break instead — a lower-case n, which an ASS renderer is free to reflow — it becomes the same real newline as the hard break, so a break the typesetter left optional arrives in the VTT as one the author insisted on.

If the styling is load-bearing — signs that carry plot, karaoke, typesetting that is part of the work — the honest options are to render the subtitles into the picture and serve a burned-in copy, or to run a JavaScript renderer that draws ASS over the video. Both cost something: the first makes the subtitles permanent and unselectable, the second adds a library, a runtime and a dependency on scripting being enabled.

For most web video, neither is warranted. Plain cues that appear, are selectable, can be switched off and can be read by a screen reader are worth more to more viewers than a design that only some of them will see. Convert, position the handful of cues that need it, style the track in CSS, and keep the ASS as the master for the version where appearance matters.