How do you add captions to an HTML `<video>` using the `<track>` element, and what distinguishes `kind="captions"` from `kind="subtitles"`?

## The markup ```html <video controls width="1280" height="720" poster="frame.jpg"> <source src="talk.webm" type="video/webm"> <source src="talk.mp4" type="video/mp4"> <track kind="captions" src="talk-en.vtt" srclang="en" label="English" default> <track kind="subtitles" src="talk-de.vtt" srclang="de" label="Deutsch"> </video> ``` `<track>` is a void element and must appear after any `<source>` children. Each one references a separate timed-text file; the media file itself is untouched, which is why captions can be added, corrected and translated without re-encoding anything. ## The attributes - **`src`** — required, the URL of the timed-text file. - **`kind`** — `subtitles` (the default when omitted), `captions`, `descriptions`, `chapters` or `metadata`. - **`srclang`** — the BCP 47 language tag of the cues (`en`, `de`, `pt-BR`). Required when `kind="subtitles"`, and worth setting always: it is what tells assistive technology and the browser menu what language the text is in. - **`label`** — the string shown in the browser's track menu. Omit it and the user picks between unlabelled entries, which is a real usability defect on a video with three translations. - **`default`** — boolean; enables this track without user action. Only one track should carry it, or the browser has to arbitrate between conflicting defaults. ## captions versus subtitles This is the part interviews actually probe, and the wrong answer — "captions are the same language, subtitles are translated" — is close enough to sound right. The real distinction is what the viewer can hear: - **`captions`** assume the audio is unavailable to the viewer. They therefore carry everything meaningful on the audio channel: dialogue, speaker identification when it is not obvious on screen, and non-speech sound that matters — `[phone rings]`, `[laughter]`, `[ominous music]`. They exist for deaf and hard-of-hearing viewers, and equally for anyone watching with the sound off in public. - **`subtitles`** assume the audio is audible but not understood. They render the dialogue as text, usually translated, and deliberately leave out sound effects because the viewer can hear them. So a same-language transcript that omits the sound of breaking glass is a subtitle track, not a caption track, and labelling it `kind="captions"` overstates what it provides. The other kinds: `descriptions` are textual descriptions of the *visual* content, meant for audio rendering to a viewer who cannot see the screen; `chapters` provide navigable segment titles; `metadata` cues are never rendered and exist to be read by script. ## WebVTT, not SRT The file format is WebVTT, and it must begin with the token `WEBVTT`: ``` WEBVTT 00:00:01.000 --> 00:00:04.000 [door slams] 00:00:04.500 --> 00:00:07.200 <v Ana>We need to talk about the deploy. ``` Cue times use a dot before the milliseconds — `00:00:04.500`, not the comma SRT uses. A renamed `.srt` will not parse. Serve the file as `text/vtt`; a wrong content type is a common reason a track silently never appears. ## The cross-origin trap Text tracks are subject to CORS. If the `.vtt` lives on a different origin from the page — a CDN or an asset domain — the response needs the appropriate CORS headers *and* the media element needs a `crossorigin` attribute: ```html <video controls crossorigin="anonymous"> <source src="https://cdn.example.com/talk.mp4" type="video/mp4"> <track kind="captions" src="https://cdn.example.com/talk-en.vtt" srclang="en" label="English" default> </video> ``` This is the number one "my captions work locally and not in production" cause, because local development usually serves everything from one origin. ## Why this belongs in markup rather than burned into the video Open captions burned into the pixels cannot be turned off, cannot be restyled for legibility, cannot be searched or translated, and force a re-encode for every correction. A `<track>` is a small text file: swap it and the fix ships. Browsers also give the user control over caption appearance through their own settings, which a burned-in track defeats. ## What the browser does with it When `controls` is present, the browser renders a captions menu listing each track by `label`, and a `default` track renders immediately. Text-track rendering is a browser behaviour rather than something the control bar owns — so a `default` track still displays in a player with custom controls, while the user's ability to switch or disable it disappears with the native menu.