WebVTT (Web Video Text Tracks) is a plain-text format for timed text that synchronizes captions, subtitles, text descriptions, chapter titles and metadata with video or audio, and it is the native text track format of HTML video in web browsers. In Video accessibility, WebVTT is the most common way to deliver closed captions and subtitles on the web, because browsers render it without plugins and users can switch tracks on or off.
The format is defined by a W3C specification and grew out of the simpler SubRip format. It keeps SubRip’s readable structure but adds positioning, styling, speaker identification and multiple track kinds, which are essential for captions that meet accessibility guidelines.
How a WebVTT file is structured
A WebVTT file is a UTF-8 text file, usually with the .vtt extension and the text/vtt media type. It must begin with the line WEBVTT, followed by a blank line and a sequence of cues, each separated by a blank line.
Each cue contains up to four parts, as summarized below.
| Part | Required | Example | Purpose |
|---|---|---|---|
| Cue identifier | No | intro-1 | Names the cue for scripting or styling |
| Timing line | Yes | 00:01.000 --> 00:04.500 | Start and end time of display |
| Cue settings | No | line:85% align:center | Position, size and alignment |
| Cue payload | Yes | One or two lines of text | The caption text, with optional markup |
Timestamps use a period before the milliseconds and may omit hours, which is a frequent difference from SubRip. Besides cues, a file may contain NOTE blocks for comments, STYLE blocks with CSS for the cue pseudo-element, and REGION blocks that define scrolling caption areas.
Track kinds and how browsers use them
In a web page, a WebVTT file is attached to a video through the HTML track element, whose kind attribute tells the browser and assistive technologies what the text represents. Choosing the correct kind matters for screen readers and caption menus.
| Kind | Content | Typical audience |
|---|---|---|
| subtitles | Translated or transcribed dialogue | Viewers who hear but do not understand the language |
| captions | Dialogue plus speaker names and sound effects | Deaf and hard-of-hearing viewers |
| descriptions | Text describing visual content | Blind users via screen readers |
| chapters | Titles for navigating sections | All viewers |
| metadata | Data for scripts, not displayed | Developers and applications |
The distinction between subtitles and captions is substantive. Captions must convey non-speech information such as music, laughter or a door slamming, while subtitles typically assume the viewer can hear the audio.
Styling and positioning features
WebVTT supports a small set of inline markup tags in the cue text: bold, italic and underline spans, class spans, language spans, ruby annotations, internal timestamps for progressive display, and voice spans that identify the speaker. Voice spans let a player show or style each speaker consistently.
Cue settings control layout. The line setting moves a cue vertically, position and size set its horizontal box, align sets text alignment, and vertical enables vertical text for languages such as Japanese. Moving captions away from important on-screen text is a practical accessibility requirement, not decoration.
Browsers apply styles through the cue pseudo-element in CSS. However, users must be able to override caption appearance through operating system or player settings, so authors should treat styling as a default, not a fixed design.
WebVTT compared with other caption formats
Caption workflows involve several formats, and conversion between them is routine. The table compares WebVTT with its main neighbors.
| Format | Syntax | Styling and positioning | Main use |
|---|---|---|---|
| WebVTT | Plain text | Cue settings, CSS, voice spans | Web players and HLS streaming |
| SubRip (SRT) | Plain text with numbered cues | Minimal, no formal standard | Desktop players and editing exchange |
| TTML and IMSC | XML | Rich, region-based | Broadcast, OTT and DASH delivery |
| CEA-608 and CEA-708 | Embedded in video signal | Limited, broadcast-defined | Television and some streaming |
| SCC | Hex-encoded 608 data | Broadcast-defined | Exchanging broadcast captions |
For adaptive streaming, HLS uses segmented WebVTT files aligned with media segments, with a timestamp mapping header to synchronize them with the video. DASH can carry WebVTT as well, although many DASH services prefer IMSC, the TTML profile designed for subtitles and captions.
Quality practices and common errors
A valid file does not guarantee accessible captions. Timing, readability and completeness determine whether captions actually serve viewers. Common guidance includes:
- Keep cues to one or two lines and roughly 32 to 42 characters per line.
- Leave each cue on screen long enough to read, typically at least one to one and a half seconds.
- Identify speakers and relevant sounds in caption tracks.
- Set the srclang and label attributes so users can pick the right language.
| Problem | Cause | Fix |
|---|---|---|
| Track does not load | Missing WEBVTT header or wrong media type | Add the header and serve as text/vtt |
| Captions blocked across domains | Missing cross-origin headers | Enable CORS and set the crossorigin attribute |
| Cues ignored | Comma used in milliseconds as in SRT | Use a period in timestamps |
| Garbled characters | File not saved as UTF-8 | Re-save with UTF-8 encoding |
| Drift over time | Frame rate mismatch after conversion | Retime against the final edit |
Validation should combine an automated syntax check with human review while watching the video. Automatic speech recognition produces a useful first draft, but it routinely misses names, technical terms and sound cues, so edited captions remain the accessibility standard. Teams should also re-check captions whenever the video is re-edited, because even a few seconds of added footage shifts every following cue.
In everyday language
WebVTT is a simple text file that tells a video player which words to show and when. Each entry has a start time, an end time and the text, such as a line of dialogue or a note like door creaks.
Web browsers read these files directly, so a viewer can turn captions on with one click. That makes videos usable for people who cannot hear the sound, and handy for anyone watching on mute.
Seen in the real world
A university publishes recorded lectures on its learning platform and must meet its accessibility obligations. Its media team generates draft captions with speech recognition, then edits them for accuracy, adding speaker labels for questions from students and notes such as applause.
The edited captions are exported as WebVTT and attached to each video as a captions track in English, with a second subtitles track in Spanish produced by a translator. Cue settings move the captions to the top of the frame during segments where the lecturer’s slides show text at the bottom.
Students who are deaf can follow every lecture, and international students switch to Spanish subtitles when needed. A plain chapters track also lets everyone jump directly to each topic in a 90-minute recording.