blob: URLs
Baseline Widely available
This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.
Blob (or object) URLs, URLs prefixed with theblob: scheme, enable integration ofBlobs andMediaSources with other APIs that are only designed to be used with URLs, such as the<img> element. Blob URLs can also be used to navigate to as well as to trigger downloads of locally generated data. They are designed as opaque identifiers (that is, you shouldn't be handwriting them) and should be managed with theURL.createObjectURL() andURL.revokeObjectURL() functions.
Blob URLs are similar todata URLs, because they both allow representing in-memory resources as URLs; the difference is that data URLs embed resources in themselves and have severe size limitations, whereas blob URLs require a backingBlob orMediaSource and can represent larger resources.
Syntax
blob:<origin>/<uuid>Usage notes
Memory management
Each time you callcreateObjectURL(), a new object URL is created, even if you've already created one for the same object. Each of these must be released by callingURL.revokeObjectURL() when you no longer need them. As long as there's one object URL active, the underlying object cannot be garbage-collected and may cause memory leaks.
Browsers will release object URLs automatically when the document is unloaded; however, for optimal performance and memory usage, if there are safe times when you can explicitly unload them, you should do so.
However, avoid freeing the object URL too early. One common anti-pattern is the following:
const url = URL.createObjectURL(blob);img.src = url;img.addEventListener("load", () => { URL.revokeObjectURL(url);});document.body.appendChild(img);Revoking the blob URL immediately after the image gets rendered would make the image unusable for user interactions (such as right-clicking to save the image or opening it in a new tab). For long-lived applications, you should revoke object URLs only when the resource is no longer accessible by the user (such as when the image is removed from the DOM).
Storage partitioning
Access to resources via blob URLs are subject to the same restrictions as all other storage mechanisms, i.e.,state partitioning. Blob URLs have an associated creator origin (which is stored in the URL itself) and can only be fetched from environments where the storage key matches that of the creator environment. Blob URLnavigations are not subject to this restriction, although browsers may enforce privacy measures such asnoopener for cross-site navigations to a blob URL.
Using object URLs for media streams
In older versions of the Media Source specification, attaching a stream to a<video> element required creating an object URL for theMediaStream. This is no longer necessary, and browsers are removing support for doing this.
Warning:If you still have code that relies oncreateObjectURL() to attach streams to media elements, you need to update your code to setsrcObject to theMediaStream directly.
Fetching with the Range header
Blob URLs support fetching with theRange header to request partial content. This is particularly useful when working with large blobs, allowing you to fetch only the necessary parts of the blob instead of the entire content. For an example, seefetching a range from a blob URL.
Examples
Valid blob URLs
blob:https://example.org/40a5fb5a-d56d-4a33-b4e2-0acf6a8e5f64Creating blob URLs
In this example, we first create aBlob from a<canvas>, create a blob URL to it, and finally attach the URL to an<img> element.
const canvas = document.querySelector("canvas");canvas.toBlob((blob) => { const img = document.createElement("img"); img.src = URL.createObjectURL(blob); document.body.appendChild(img);});Specifications
| Specification |
|---|
| File API # url |