Caption Format Reference
WebVTT File Format (.vtt)
WebVTT is what a browser expects. It looks like SRT with periods instead of commas, but underneath it carries cue positioning, CSS styling, speaker tags and regions — which is why converting SRT to WebVTT is easy and converting WebVTT to SRT quietly throws things away.
What can a WebVTT file be converted to?
WebVTT converts cleanly to SRT, TTML, IMSC and DFXP, all of which are text-based and time-based in the same way. Converting to SCC, MCC or EBU-STL additionally requires a frame rate, because WebVTT stores milliseconds and those broadcast formats store frames.
WebVTT at a glance
WebVTT is a W3C specification rather than a convention, so a valid file is genuinely valid everywhere. The variation between players is in how much of the optional styling they choose to render.
| Property | Value |
|---|---|
| Full name | Web Video Text Tracks |
| Extension | .vtt |
| Specification | W3C WebVTT |
| File encoding | UTF-8, mandatory |
| Required header | The file must begin with the word WEBVTT |
| Timing | Millisecond precision, written HH:MM:SS.mmm with a period |
| Frame rate | None. WebVTT is frame-rate agnostic |
| Timing model | Explicit start and end time on every cue |
| Positioning | Percentage-based cue settings: line, position, align, size |
| Styling | Inline tags plus CSS in STYLE blocks, using ::cue selectors |
| Delivery | HTML5 <track>, HLS and DASH |
| Closed Caption Creator | Read and write |
For the wider timed-text family and how WebVTT compares, see TTML, DFXP and IMSC explained.
What WebVTT can and cannot carry
WebVTT holds considerably more than most people use. Players differ in what they render, so the practical question is not only what the format supports but what your target player honours.
| Capability | Supported | Notes |
|---|---|---|
| Dialogue text | Yes | UTF-8, so every script is available |
| Explicit end times | Yes | Every cue carries a start and an end |
| Positioning | Yes | As percentages of the video frame, not a character grid |
| Text alignment | Yes | align and position cue settings |
| Italics, bold, underline | Yes | Specified inline tags, not a convention |
| Text colour | Yes | Via CSS classes and ::cue selectors. Browser support varies |
| Speaker identification | Yes | The <v Speaker> voice tag |
| Roll-up captions | Yes | Through REGION blocks with scroll:up |
| Vertical text | Yes | The vertical cue setting, for Japanese and Chinese layouts |
| Comments | Yes | NOTE blocks, ignored by players |
| Frame-accurate timing | No | Milliseconds do not align to a frame boundary |
| Two languages in one file | No | One track per language, selected by the player |
Who asks for WebVTT files?
WebVTT exists because HTML5 needed a caption format browsers could parse natively. Anywhere video plays in a browser, this is the format.
- HTML5 video players, through the
<track>element. - HLS and DASH streaming, where WebVTT is segmented alongside the video.
- Video platforms and CMSs that render captions in the page rather than burning them in.
- Podcast and audio players offering transcripts synchronised to playback.
- Chapter markers and metadata tracks, which use the same file syntax with a different track kind.
If the destination is broadcast rather than the web, the deliverable will be SCC, MCC or EBU-STL instead. Many workflows produce both from one project.
How do I open a WebVTT file?
A WebVTT file is plain UTF-8 text and opens in any editor. The first line must read WEBVTT; if it does not, no browser will load the file regardless of how correct the rest of it is.
Below the header, cues are separated by blank lines. An optional identifier line can sit above the timing line, and anything after the timing on the same line is a cue setting rather than text.
A caption editor is worth using once cue settings and CSS are involved, because the effect of line and position values is difficult to judge without seeing them against picture.
Converting WebVTT to another format
Converting out of WebVTT is mostly about what happens to the cue settings. The text and timing always survive. Positioning survives only where the target has somewhere to put it.
| Convert WebVTT to | What survives | What to watch for |
|---|---|---|
| SRT | Text, line breaks, italic tags | Cue settings and CSS are discarded entirely. Periods become commas and the header line is removed. |
| TTML / IMSC | Text, styling, positioning | Percentage cue settings map onto TTML regions. Review the result — the two positioning models are similar but not identical. |
| SCC | Text, italics, approximate placement | Percentages snap to the 32 by 15 character grid, CSS colours reduce to seven, and timing rebases to 29.97 fps. |
| MCC | Text, italics, approximate placement | As SCC, but the target frame rate is a choice rather than fixed, and 708 services can carry more styling. |
| EBU-STL | Text and approximate placement | Positions become teletext rows, and a 25 fps timing base is required. |
| DFXP | Text, styling, positioning | Effectively the TTML conversion under a different extension. Confirm which profile the platform expects. |
| Transcript (DOCX, TXT, CSV) | Text | Timing, positioning and speaker tags are dropped. Voice tags can be preserved as speaker labels if the export supports it. |
Converting another format to WebVTT
Converting into WebVTT is one of the easier conversions in captioning, because WebVTT can hold nearly everything the source formats carry. The work is in mapping positioning models rather than losing data.
| Convert to WebVTT from | What carries over | What the conversion has to decide |
|---|---|---|
| SRT | Text and line breaks | Almost nothing. Add the WEBVTT header, change commas to periods, and confirm the file is UTF-8. |
| SCC | Text, italics, approximate placement | How to express a character grid as percentages, and whether to reproduce 608 colours as CSS classes the player may not load. |
| MCC | Text, italics, placement | Which caption service to read before the same grid-to-percentage mapping as SCC. |
| TTML / IMSC | Text, styling, positioning | How to flatten regions into cue settings. Rich font and size styling has no direct WebVTT equivalent. |
| EBU-STL | Text, colour, placement | Teletext rows become percentages, and frame timing converts to milliseconds. |
| PAC | Text, colour, placement | The source code page must be read correctly so non-Latin text survives into UTF-8. |
Closed Caption Creator reads and writes every format in both tables. See the full file format support list, or the conversion API and CLI for batch workflows.
Where WebVTT files go wrong
WebVTT failures are usually all-or-nothing: the browser either loads the track or it does not, with no error the viewer can see.
- A missing or malformed header. The file must start with
WEBVTT. A stray blank line, a byte order mark in the wrong place, or a lowercase spelling stops the track loading. - A comma in the timestamp. An SRT renamed to
.vttis not a WebVTT file. The milliseconds separator has to be a period. - Cue settings the player ignores. Positioning is specified, but support differs between browsers and players. Test placement in the actual player rather than assuming.
- HLS timestamp offsets. Segmented WebVTT in an HLS stream carries a timestamp map. Converting a segmented track back to a single file without accounting for it puts every cue at the wrong time.
For the wider comparison between WebVTT and the XML timed-text family, see TTML, DFXP and IMSC explained.
WebVTT conversion questions
Common questions about moving captions into and out of the WebVTT format.
No. Two things have to change. The file must begin with a line reading WEBVTT, and the milliseconds separator in every timestamp must be a period rather than a comma. Without both, browsers reject the track. The encoding must also be UTF-8, which SRT does not guarantee.
Yes, completely. Cue settings such as line and position have no equivalent in SRT, and neither does CSS styling. The text, line breaks and timing survive, and italic tags usually survive as a convention. If placement matters, keep the WebVTT as the master and treat the SRT as a derived copy.
Because ::cue styling depends on the player. Browsers implement different subsets of WebVTT CSS, and many embedded players strip the STYLE block entirely. Colour applied through CSS classes is a presentation hint, not a guarantee, which is a real difference from broadcast formats where colour is part of the caption data.
Yes, using REGION blocks with a scroll:up setting, which is the closest web equivalent to 608 roll-up. Support is inconsistent across players, so live-style roll-up on the web is less reliable than pop-on cues. For broadcast roll-up, SCC or MCC remains the right container.
It depends on the platform's requirement rather than the formats' merits. WebVTT is native to browsers and HLS. IMSC carries richer styling and positioning and is what many OTT platforms specify for their own players. Check the delivery spec; producing both from one project is routine.
Segmented WebVTT in an HLS stream carries an X-TIMESTAMP-MAP header that relates cue times to the media timeline. If a conversion concatenates the segments without applying that offset, every cue lands at the wrong time. Re-extract with the mapping applied rather than shifting the result by hand.
Author once, deliver web and broadcast
Closed Caption Creator writes valid WebVTT with cue positioning and styling intact, from the same project that produces your SCC, MCC and IMSC deliverables.
Preview placement against picture before export, and QC reading speed and line length across every output format.