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 the blob: scheme, enable integration of Blobs and MediaSources 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 the URL.createObjectURL() and URL.revokeObjectURL() functions.
Blob URLs are similar to data 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 backing Blob or MediaSource and can represent larger resources.
Syntax
blob:<origin>/<uuid>
Usage notes
Memory management
Each time you call createObjectURL(), a new object URL is created, even if you've already created one for the same object. Each of these must be released by calling URL.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 URL navigations are not subject to this restriction, although browsers may enforce privacy measures such as noopener 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 the MediaStream. This is no longer necessary, and browsers are removing support for doing this.
Warning:
If you still have code that relies on createObjectURL() to attach streams to media elements, you need to update your code to set srcObject to the MediaStream directly.
Examples
Valid blob URLs
blob:https://example.org/40a5fb5a-d56d-4a33-b4e2-0acf6a8e5f64
Creating blob URLs
In this example, we first create a Blob 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 |
Browser compatibility
Loading…