What is a VTT file?

VTT is a plain-text format you can open in any editor. It is used for subtitling and the web.

The extension is .vtt, and the full name is WebVTT. Both matter less than what the file can hold, which is what the rest of this page is about.

W3C published it in 2010. The specification is WebVTT.

Age is worth knowing here for one practical reason: the older a format is, the more programs have had time to learn it.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

VTT stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

VLC and Subtitle Edit read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

Every current browser reads it.

That makes it a safe thing to put on a page or attach to a message without wondering what the other end has installed.

VTT is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

HTML video takes subtitles through a track element pointing at a VTT file, and that is the only subtitle format it accepts. Not SRT, not ASS — a browser handed either will ignore it. This single fact accounts for most of the traffic to this page: somebody has subtitles, has put them next to a video on a web page, and nothing appears.

The format itself is deliberately close to SubRip so that converting is trivial. Cues are numbered optionally rather than compulsorily, timestamps use a full stop before the milliseconds rather than a comma, and the file must open with the word WEBVTT on its own first line. That header is not decoration — a file without it is rejected outright.

Four causes, in the order worth checking. The WEBVTT header is missing, usually because the file was produced by renaming an SRT. The timestamps still use commas, for the same reason. The track element is missing its kind and srclang attributes, or has no default attribute and the viewer never turned subtitles on. Or — the one that wastes the most time — the file is being served from a different origin without the right cross-origin headers, and the browser refuses it silently.

That last case is worth dwelling on because it produces no visible error. The video plays, the subtitle menu is empty, and nothing in the page suggests why. A VTT served from the same origin as the page avoids it entirely, which is the simplest reason to host subtitles alongside the video rather than on a separate asset domain.

Every cue can carry settings after its timestamp — a vertical position, a horizontal alignment, a width, a line number. This is what SRT has no way to express, and it is the practical reason to prefer VTT for anything more considered than a straight transcript.

The usual application is moving a caption out of the way. Subtitles default to the bottom, which is exactly where broadcasters put lower thirds and where a video player puts its own controls. A line setting that pushes a cue to the top for those few seconds is two words in the file and solves a problem no amount of styling elsewhere can.

VTT allows a handful of inline tags — bold, italic, underline — and voice tags naming the speaker, which is how a transcript distinguishes two people without writing their names into the text. A style block inside the file, or CSS in the page targeting the cue pseudo-element, can then set font, colour and background.

What browsers actually honour varies, and it is the part of the specification with the weakest implementation. Assume italics and speaker distinction will work everywhere and treat anything beyond that as an enhancement. A subtitle track that becomes unreadable when the styling is ignored has been designed against the format rather than with it.

A VTT file does not have to contain subtitles. The track element has a kind attribute, and the other values are genuinely useful: chapters produces a navigable list of sections in players that support it, descriptions carries audio description text for screen readers, and metadata carries arbitrary cues that JavaScript can react to as the video plays.

That last one is how interactive transcripts, synchronised slides and timed annotations are built. The cues fire as the playhead reaches them, the page does whatever it likes with them, and nothing is displayed unless the page displays it. It is a small scheduling system hiding inside a subtitle format.

The track element distinguishes captions from subtitles, and the distinction is not pedantry. Subtitles assume the viewer can hear and translate the dialogue. Captions assume the viewer cannot hear and therefore include the non-speech information — a door slamming, music starting, who is speaking off-screen.

For most public sector bodies and a growing number of businesses, captions on prerecorded video are a requirement rather than a courtesy, under WCAG and the accessibility legislation that references it. A track marked as captions that contains only translated dialogue satisfies the markup and not the obligation, which is a distinction auditors do notice.

Automatic transcription, mostly. Every major platform and most transcription services will export WebVTT, and the machine output is good enough to be worth correcting and nowhere near good enough to publish unread — proper nouns, overlapping speech and technical vocabulary are where it fails, and those tend to be the words that carry the meaning.

The other route is conversion. Editing subtitles is far better supported in SRT by desktop subtitle software, so a common workflow is to correct and time in SRT and convert to VTT at the point of publishing. That is a sound division of labour as long as one file is the master and the other is generated, rather than two copies drifting quietly apart.