How to Download Video Subtitles: Formats and Limitations
Seeing subtitles in a player doesn’t mean there’s a subtitle file you can save. Before you can download them, you need to know how this video carries its text, because that decides whether they can be saved as a separate .srt or .vtt file, muxed into the video, or not saved as text at all.
In practice there are four cases. A web video’s subtitles are usually one of these:
- A separate file the player loads next to the video.
- A text track inside the media, stored beside the picture and sound.
- A rendition in a stream, listed in an HLS or DASH manifest like the audio tracks are.
- Pixels in the picture, called burned-in or hardcoded subtitles.
The first three are text and can usually be saved if the site exposes them. The fourth is only a picture of text. The rest of this guide shows how to tell them apart in Chrome, what each one lets you do, and how to choose between a separate subtitle file and one combined with the video.
What kind of text is it?
1. A separate subtitle file
On the web, subtitles for a plain video are commonly attached with the HTML <track> element, which points to a timed text file shown alongside the media. According to MDN’s <track> reference, the tracks are formatted in WebVTT (.vtt files), and a media element can have several, for example in different languages. WebVTT is the W3C format for time-aligned text tracks.
Such a file is the easiest case: it’s already separate from the video, so saving it means requesting that file. Not every site uses <track>; many players load a .vtt, .srt or JSON file with their own code and draw the text themselves. The file is still there, but the page’s HTML won’t show it.
2. A track inside the media
Subtitles can also be packaged in the media container. As Mux’s FFmpeg guide puts it, embedded subtitles are stored as a text track alongside the other tracks in the container, which means they can be extracted without altering the video. This is typical for a file you’ve already downloaded; a streaming player is more likely to use case 1 or 3.
3. A rendition in a stream
HLS and DASH can describe subtitles as renditions of their own. In an HLS master playlist, an EXT-X-MEDIA tag with TYPE=SUBTITLES points to a separate media playlist for the text, and the HLS specification (RFC 8216) defines WebVTT segments for carrying it. That means the subtitles may arrive as many small segments, not as one file, and a downloader has to fetch and join them.
HLS has a further variant. The same tag with TYPE=CLOSED-CAPTIONS must not have a URI, according to the specification: those captions live inside the video stream itself instead of in a playlist of their own. If that is how a stream carries its captions, there’s no separate text resource to request. The captions aren’t necessarily lost, though: in-band CEA-608 or CEA-708 data can sometimes be extracted by tools that read it from the video stream, but whether MAX exposes it as a track isn’t something this article can promise. DASH can likewise list text tracks as separate sets in its manifest; the DASH guide explains how a manifest groups tracks. For the HLS mechanics, see How to Download M3U8 / HLS Videos in Chrome.
4. Burned-in subtitles
Burned-in (hardcoded) subtitles are part of the video image. Mux notes that they can’t be extracted as a separate file, because they don’t exist as parsable text. They’re pixels. Getting text out of them would mean reading the frames, which is optical character recognition, a different and imperfect process that no ordinary downloader does.
If you can’t switch the subtitles off in the player, and there’s no language menu, burned-in text is a likely explanation. It isn’t a certain one, because some players don’t offer a menu even when the text is a separate track.
How to tell which case you have
None of these checks is conclusive alone, but together they narrow it down:
| Observation | What it suggests |
|---|---|
| The player has a captions or language menu, and the text changes when you switch | A real text track exists, whichever case 1 to 3 carries it. |
| The text can’t be turned off and there are no language options | Likely burned in, though a player may simply not expose its track. |
DevTools Network, filtered for vtt or srt, shows a file loading when you enable captions |
A separate subtitle file (case 1). Many sites name it differently, so an empty filter isn’t proof of absence. |
Filtering for m3u8 shows a master playlist with TYPE=SUBTITLES entries |
A subtitle rendition in an HLS stream (case 3). |
A TYPE=CLOSED-CAPTIONS entry with no URI |
Captions carried inside the video stream, with no separate playlist to fetch. |
A downloaded file shows a subtitle stream when inspected with a tool like ffprobe |
An embedded track (case 2). |
A blob: video address doesn’t tell you where the captions come from. It’s the video element’s source, and the subtitle text may be loaded from somewhere else entirely.
Captions or subtitles?
The two words are often used interchangeably, but they aren’t identical. MDN’s <track> reference distinguishes subtitles, which transcribe or translate dialogue for viewers who can hear the audio, from captions, which also describe sound effects, music cues and other audio information, for people who can’t hear it. Whether a given publisher labels them consistently is another matter. What matters for downloading is only that the text exists as a track the page exposes.
Separate file or muxed into the video?
Once you know a text track exists, the next choice is how to keep it.
Save it as a separate file when you want to edit, translate, reuse or archive the text, or when your player loads a subtitle file next to the video. Mux lists localization, accessibility and automation as typical reasons to extract subtitles: a separate file is easier for editors and tools to work with. It also keeps working with any video file you have.
Mux it into the video when you want one file that carries the picture, sound and subtitles together, for instance for a device that handles only a single file. Muxing places the tracks in the same container without altering the video, but the container must support that subtitle format. That’s one place where a combination can fail, and it’s why it’s useful to have the separate file as a fallback.
Common formats:
| Format | Notes |
|---|---|
| SRT | Simple timed text. Very widely supported by players and editors, with little formatting. |
| VTT (WebVTT) | The format browsers use for <track>. Handles basic styling and positioning, and is the natural choice for web playback. |
| ASS | Meant for complex styling and positioning, which Mux points to as its use. |
| Original format | The track as the source delivered it, with no conversion. Useful when you want to avoid losing information. |
Converting to a plainer format can drop styling, so choose the original format when you need to keep it.
Download subtitles with MAX
MAX can save available subtitle tracks as SRT, VTT, ASS or their original format, and can combine selected video, audio and subtitle tracks into one file or save them separately. This applies when the source exposes a supported track. It doesn’t create captions that the site doesn’t publish, transcribe speech, or read burned-in text.
- Install MAX from the Chrome Web Store (free).
- Open the page, start the video, and switch the captions on in the player so the site requests them.
- Open the MAX popup and choose the subtitle track you want from the detected media, or select the video, audio and subtitle tracks to combine, along with the output format.
- Download.
If no subtitle track shows up, enable the captions in the player first and try Force Detection. MAX’s changelog is candid that stricter detection to keep browsing less intrusive can miss media that was previously found, subtitles in particular, so it’s worth reporting a track that should have been found. MAX doesn’t support DRM-protected media or YouTube.
If you want to pick up several tracks at once, remember that each is its own download. Selecting five audio and five subtitle tracks results in ten operations, as MAX’s changelog describes.
When there’s no subtitle track to save
There are three different situations here: no standalone subtitle resource, caption data embedded in the media, and text burned into the pixels. Only the last has no text to recover. A downloader that collects subtitle tracks may find nothing in any of them. That happens when:
- the subtitles are burned into the picture,
- the site draws them from a source the page never exposes to the browser as a file or stream,
- they’re closed captions carried inside the video stream, which have no separate resource to fetch (specialized tools may extract that in-band data, but a downloader that only collects separate tracks won’t see it), or
- the media is protected, in which case nothing here applies, and nothing in this article helps bypass it.
In those cases, ask the publisher for a transcript or subtitle file, or use the platform’s own download and caption options. A generated transcript is a different thing: it’s made by a speech recognition service rather than the original subtitles, and it can contain mistakes.
The shortest path is therefore: switch the captions on, find out how the page loads them, and save them either separately or with the video, depending on what you plan to do with them.