Short answer: when a page plays HTML5 video through a script-fed source, the element’s address is often created at runtime as a blob: reference to data the page already holds — frequently fed by MediaSource buffers. A blob: URL is a same-document handle, not an addressable resource: it cannot be pasted into a downloader, doesn’t work in another tab, and dies with the page. The video you want is the bytes behind it, which means capturing the network requests instead of the element’s src.
What a blob URL is, and what it is not
- It is an in-memory reference.
URL.createObjectURL()registers aBloborMediaSourcestream and returns an address scoped to the current document. Nothing on a server is named by it. - It has no network meaning. Requesting a
blob:address from outside that document resolves to nothing — which is exactly the “failed — network error” you were shown. - It dies with the tab. Even inside the page, the URL is revoked once the script releases it.
So “how to download a video using a blob URL” has an uncomfortable answer: you don’t. You download what produced the blob. The same applies to “download video from a web player with no URL” — there is a URL, it is simply behind the curtain, in the request log.
Finding what’s behind the blob
Open the Network panel, filter to media, and play
The real addresses appear as the player fetches them. This is the general method described in finding a video’s source URL.
Interpret the shape
Single .mp4 requests are simple. .m3u8 or .mpd plus many fragments means the blob was built from a stream — and the blob is only the last mile of a fetch plan. Fragmented MP4 (.m4s with an init segment) is the common case; combining those is covered in merging fragmented MP4.
Then save or merge
Progressive media: fetch and play. Segmented media: fetch all parts in manifest order, then mux into MP4 with stream copy. Do not try to salvage the blob handle from the element.
Save HTML5 video from a website — the simple case
Plenty of HTML5 video is not blob-backed at all: a plain <video src="…mp4">, served directly. Then:
- Right-click → “Save video as…” works when the element exposes a real, same-origin-addressable source. It fails silently in intent when the source is a blob.
- Copying the
srcfrom the inspector works when it is an ordinary URL. - “Download HTML5 video source from Chrome” is the same operation; the browser makes no difference here, since the deciding factor is whether the source is a URL or an object reference.
A quick tell: if the address starts with blob: or data:, the element has no remote source to copy. If it starts with https://, you have something to work with — subject to expiry and authorisation.
Custom web players
“Download video from a custom web player” is usually a question about who wrote the player, not about the media. Library players (HLS/DASH.js-based, or a framework wrapper) still fetch over HTTP with the same shapes; a custom player may add signed parameters, token refresh or per-segment authentication. The method does not change — observe the requests — but expect more of them to be short-lived, and expect the first attempt at a naive fetch to return 403. That behaviour is explained in 403 and 401 download errors.
Save blob video from browser to MP4, on Mac and elsewhere
Read literally, “save blob video from browser to MP4” and “download video from blob URL on Mac” describe the wrong starting point. The workable route is the same on macOS and Windows:
- Recover the underlying requests (Network panel), not the blob.
- Fetch the media in the shape it arrives.
- Mux or copy into MP4. FFmpeg’s container documentation covers MP4 packaging; segment combination is in its concatenation guide.
On macOS specifically, remember that converting at the end is optional and usually harmful: if what you fetched is already H.264 in MP4, no conversion is needed, and QuickTime will play it. Re-encode only when a codec genuinely requires it.
Screen recording is the fallback, not the method
Because blob-backed playback frustrates people, capture-from-screen becomes the default workaround. It costs a generation of quality, ties the file to your display resolution, and drops the original audio path. Recording is a reasonable last resort for content that is genuinely un-fetchable in your session — it is not a better technique than fetching the rendition.
Boundaries
MSE itself is neutral: it is used both for ordinary adaptive streaming and for encrypted media. Where a player negotiates encryption (EME key systems), the buffers are decrypted media you cannot simply reassemble into a file, and nothing on this page applies. Saving content you may watch, in clear, is the scope; access controls are not an obstacle to be solved.
FAQ
How do I download a video using a blob URL?
You can't use the blob directly — it is an in-memory handle scoped to the page. Capture the network requests that produced it and download those.
Why does copying the blob address give a network error?
Because a blob: URL resolves only inside the document that created it, so no downloader and no other tab can fetch it.
Can I save HTML5 video from a website?
Yes. If the element's source is a real URL, take it; if it is a blob, capture the requests behind it and reassemble.
How do I download video from a web player with no URL?
There is a URL — in the Network panel. Players with no addressable src are fetching fragments, which you can list and merge.
Can I save blob video to MP4 on Mac?
Yes, via the underlying requests; then mux to MP4. Conversion is only needed if the codec genuinely requires it.
Is screen recording a good substitute?
Only as a last resort. It loses a generation of quality and cannot recover audio better than the source.