How to Download an Embedded Video in Chrome

Published October 31, 2026

Whether you can download an embedded video in Chrome depends on two separate things: whether you’re allowed to keep it, and what the page actually loads to play it. The first is about permission. The second is plumbing, and it’s why right-click so often gives you nothing useful.

This guide starts with the publisher’s own options, then explains what is happening under the player, how to read it in Chrome DevTools, and when an extension saves you from doing that by hand.

Why the player has no “Save video” option

“Embedded” only describes where a video appears: inside a page, often in a player served from another site in an iframe. It says nothing about how the media arrives.

Three delivery patterns cover most of what you’ll meet:

One file. The page’s <video> element points at a single MP4 or WebM, directly or through <source> elements, as the HTML standard describes. The browser may fetch it in pieces using HTTP range requests, which is common for seeking, but it is still one file on the server.
A playlist of short segments. HLS or DASH split the video (and often audio) into many small files, described by a manifest, so quality can adapt to your connection. The playlist and segment mechanics are covered in How to Download M3U8 / HLS Videos in Chrome.
Something assembled by JavaScript. The player can fetch data itself and hand it to the browser through Media Source Extensions, or build a Blob in memory. Either way the <video> element ends up with a blob: address.

That last address is where people get stuck, and it’s easy to misread. A blob: URL is a reference to an object that lives inside your tab. It tells you the page created the data locally; it does not tell you what the data was. It can be a segmented HLS or DASH stream fed through Media Source Extensions, but it can equally be a complete file the page downloaded first and wrapped in a Blob. You can’t fetch a blob: address from outside the tab, so the useful question is what the page requested before it made one.

Encrypted playback through Encrypted Media Extensions is a separate layer that can sit on top of any of these. There the content is decrypted only inside the browser’s player, which is a deliberate protection rather than a missing button.

Start with what the publisher offers

Before anything technical, look for the site’s own route. It’s the only method that doesn’t depend on how the player works.

A Download link near the player, in a three-dot menu, or in the player’s settings.
A download option in the platform’s account area, if the video is yours or you’ve been granted access. Course platforms, hosting dashboards and webinar tools often have one.
An official offline mode in the service’s app.
If you run the page, the original file you uploaded.

A file offered this way is a normal Chrome download and shows up in its downloads list. If there’s no option, ask the owner; people who publish video are often happy to send a file.

This is also the point to settle permission. Being able to save a video doesn’t mean you may keep or reuse it: in the United States, for example, the Copyright Office explains that the owner controls reproduction of a work, and the site’s terms add their own limits. Your own uploads, openly licensed material and permitted personal copies are fine; paid courses and other people’s work usually aren’t. Everything below assumes you’re in the first group, and none of it covers getting around logins, paywalls or protection.

Read what the page actually loads

When there’s no download button, the most useful thing you can do is find out which of the three patterns you’re dealing with. Chrome DevTools shows it, and it determines every later choice.

Open the page, then DevTools (F12, or Cmd+Option+I on Mac), and go to the Network tab.
Tick Preserve log, then reload the page with DevTools still open. Requests made before you opened it won’t be there.
Press play and let the video run for a few seconds.
Clear the filter and look at everything, not just the Media button. Chrome’s resource-type filters group requests by how the page asked for them. A plain <video> file usually lands under Media, but a player that fetches data with JavaScript shows up under Fetch/XHR, so filtering only on Media can make a video that clearly loaded look like it loaded nothing.
Sort by Size or use filters such as mime-type:video/mp4 or larger-than:1M to pull the heavy requests to the top, and click one to read its headers and response.

Don’t rely on the file extension. URLs can carry tokens and query strings, have no extension at all, or use a misleading one. The signals that hold up better are the response’s Content-Type, how many requests there are, and what the response body actually contains.

Three things you might see

The following are illustrative patterns, not captures from a specific site. Real sites vary, but these are the shapes to recognize.

A. One big request: a direct file. You see a single request, or a few repeats of the same URL, with a large transfer size, a Content-Type such as video/mp4 or video/webm, and often status 206 Partial Content with Accept-Ranges and Content-Range headers. The 206 is just the browser asking for byte ranges so you can seek without downloading everything. This is one ordinary file. If it’s public and you’re permitted to keep it, opening the request URL in its own tab lets you use Save video as…. If the URL stops working outside the page, it depends on something the page supplies, such as a session or a signed token, and you should go back to the publisher’s route rather than copy those credentials anywhere.

B. Many small requests, plus a manifest: a streaming playlist. You see one small text request and then a long run of near-identical requests, often a few seconds of video each. Click the small one:

A response that starts with #EXTM3U is an HLS playlist. A master playlist lists variants with #EXT-X-STREAM-INF lines; a media playlist lists segments with #EXTINF. Servers usually label it application/vnd.apple.mpegurl or application/x-mpegURL, and RFC 8216 defines the format.
A response that begins with an <MPD XML element is a DASH manifest, usually served as application/dash+xml.

The repeated requests are the segments. They typically come back as video/mp2t or video/mp4, and with DASH or modern HLS, audio and video are often requested separately. Saving any one of them gives you only a few seconds of the video. Depending on the stream, that may be picture without sound, audio only, or both together, since an MPEG-TS segment can carry multiplexed audio and video. This is the pattern where doing it by hand is a lot of work, and where an extension earns its place (more on that below).

C. A blob: source in the Elements panel. Select the video in the Elements tab and you may find <video src="blob:https://…">. That address alone tells you nothing, so look at the Network log from before it appeared:

One large video/mp4 request followed by a blob means the page downloaded a whole file first and wrapped it in a Blob. Case A applies, even though the player no longer exposes the URL.
A manifest followed by many small segment requests means a player built on Media Source Extensions is assembling the stream. Case B applies.
Nothing that looks like media at all is the inconclusive one. The player may have loaded before you started recording, the request may be hiding under a category you filtered out, or the data may be arriving in a form you can’t read from the log. Reload with Preserve log on before drawing conclusions.

One more thing to look for in a manifest: an HLS #EXT-X-KEY line with a method other than NONE, or a DASH ContentProtection element, indicates that segments are encrypted or protected (METHOD=NONE explicitly means they aren’t). Plain AES-128 HLS encryption isn’t necessarily DRM, but MAX’s FAQ lists encryption without an available key as unsupported. Entries naming a DRM system, such as Widevine or FairPlay, mean the stream is protected, and that’s where both the manual route and the extension route end.

Let an extension do the reading

Case A you can do by hand in a minute. Case B is where doing it manually means resolving a manifest, choosing a quality, fetching every segment in order, pairing audio with video and joining them. An extension that watches the page’s media requests removes all of that, and this is what MAX Video Downloader is for.

MAX supports direct files such as MP4 and WebM as well as HLS (.m3u8) and DASH (.mpd) streams, including separate audio and video tracks and subtitles, as long as the media isn’t DRM-protected. You pick the quality, and the basic workflow works in Chrome without the optional desktop app.

Install MAX from the Chrome Web Store (free).
Open the page and start the video so it requests its media.
Open the MAX popup, choose the detected video and quality, and download.

MAX only sees media the page has loaded, which is the same thing you were looking for in DevTools, so the two methods agree. It also means a few things are outside its reach: its documentation says it doesn’t work on YouTube, on DRM-protected media, or on pages that never expose a usable media source.

When MAX finds nothing

An empty popup is an observation, not a diagnosis. Several different situations produce it, and they call for different responses:

What you see	What it could mean	What to try
Popup empty, video not started	The page hasn’t requested media yet	Press play, reopen the popup
Popup empty, playing fine	Detection missed it, or it loaded before MAX was watching	Refresh, play again, then try Force Detection, a limited check listed in the FAQ
Detected, but the download fails at once	The detected link expired (an HTTP 403 after waiting too long), or the format isn’t supported, such as DASH with complex index nesting or encryption without a key	Refresh the detection and retry; if it persists, see the FAQ failure notes
Network log shows a manifest naming a DRM system	Protected stream	Not downloadable; use the publisher’s offline option
Network log shows nothing media-like even after a reload	The page doesn’t expose a usable source to the browser	Ask the owner

Treat refresh and Force Detection as quick diagnostics rather than fixes: if the DevTools log shows protected content or no source, repeating them won’t change that.

Screen recording, honestly

Recording the screen captures playback, not the file. It’s an option when no download route exists and you’re allowed to keep a copy. The tradeoffs are plain: you record in real time, quality is limited by your capture settings, and anything on screen ends up in the recording. Protected video often records as black, and recording it to avoid the protection isn’t something this guide endorses. A site’s terms may forbid recording even where it works.

Which method fits which situation

Situation	Best first move	Realistic outcome
The site shows a download button or menu item	Use it	A normal file; no tools needed
Network log shows one large `video/mp4` or `video/webm` request	Open the URL and use Save video as…, or an extension	One file, if the URL is reachable outside the page
Manifest plus many segments (HLS/DASH)	Extension such as MAX	Usually a merged file at your chosen quality, if supported and unprotected
`blob:` source	Check the Network log to see which case it really is	Depends on what the page loaded before the blob
Manifest naming a DRM system, or YouTube	The service’s official offline mode	Not downloadable with these methods
No usable source ever appears	Ask the owner	Nothing to download

The sequence that saves the most time is: look for an official option, open the Network panel to see what the page loads, and let that decide whether you need a file link, an extension, or a different route altogether. An embedded video that plays is not necessarily a file you can download. Whether it is depends on what the page fetched, and that is something you can read for yourself.