skip to content
Posts · July 2026

JavaScript Blobs - A Deep Dive

By Harjith L R S·20 July 2026 ·6 min read

web· js
Puzzled Web Developer, figuring out js blobs

Introduction

The first time I worked with JavaScript Blobs, I assumed they were just a way of representing a file. But the more I used them, the more questions I had.

Where is a Blob actually stored? Is it sitting in RAM? Does the browser write it to disk? If Blob objects are garbage collected like every other JavaScript object, why do we have to manually call URL.revokeObjectURL()? And what exactly does blob.stream() do that arrayBuffer() doesn’t?

I ran into these questions while building a frontend that accepted a ZIP file, extracted its contents entirely inside the browser, and rendered the uploaded website inside an iframe without ever touching a backend server.

That rabbit hole led me through the File API specification, browser implementations, and a lot of experiments. In this article we’ll look beyond the API surface and understand how browsers actually treat Blobs—from their lifecycle and storage abstractions to object URLs.

Blob & File: Like Parent, Like Child

You’ll often hear developers use Blob and File interchangeably, and for most day-to-day use cases, that’s perfectly fine. But they’re not the same thing. The relationship is actually quite simple: File extends Blob. A Blob is immutable binary data with an associated MIME type. A File is that same Blob, with additional metadata describing the original file on disk.

Why Blobs where needed?

Today, it’s normal for a web application to crop images, compress videos, generate PDFs, unzip archives, or even edit documents entirely inside the browser. But in the early days of the web, browsers weren’t designed for this kind of work.

The browser’s primary responsibility was to display documents, not manipulate files.

The only standard way to upload a file was through an HTML form.

<form enctype="multipart/form-data">
    <input type="file" name="document" />
</form>
File processing before js blobs

Notice something missing?

JavaScript wasn’t involved.

The browser acted purely as a courier. It could send the file to a server, but it couldn’t inspect its contents, modify it, generate a new file, or even create binary data from scratch. This meant even simple operations depended on a backend.

Every operation required sending potentially large files across the network, increasing bandwidth usage, latency, and server costs. It also meant sensitive files had to leave the user’s machine, which wasn’t ideal for privacy. As web applications evolved, this model became increasingly restrictive. Developers wanted to build richer applications that could manipulate binary data directly in the browser without depending on a round trip to the server. This need led to the File API, which introduced the Blob interface as a standardized representation of immutable binary data.

This seemingly simple abstraction unlocked a huge range of client-side capabilities that are commonplace today:

  • Image editors like Photopea can export PNGs and PSDs without a backend.
  • PDF libraries can generate downloadable reports entirely in the browser.

Blob Storage: Where are Blobs actually stored?

One of the biggest misconceptions about Blobs is that they’re always stored in memory. In reality, JavaScript doesn’t know—and isn’t supposed to know—where a Blob’s data lives.

The File API intentionally leaves storage as an implementation detail. Depending on the browser, the size of the Blob, and the current memory pressure, the underlying bytes might be kept entirely in RAM, placed in shared memory, written to a temporary file, or even stored on disk. Browsers are free to move this data around whenever it improves performance or reduces memory usage.

This abstraction is intentional. Imagine if applications assumed every Blob lived in RAM—browser vendors would lose the flexibility to optimize storage strategies as hardware and operating systems evolve. Instead, the browser exposes a simple Blob interface while hiding all the complexity of managing the underlying data.

So if someone asks, “Is my Blob stored in RAM?”, the most accurate answer is:

Wherever the browser decides is most appropriate.

As JavaScript developers, we interact with the Blob, not with where its bytes are physically stored.

Blob URLs: Bridging JavaScript and HTML

Suppose you’ve just created a Blob:

const blob = new Blob(["Hello, Blob!"], {
    type: "text/plain"
});

At this point, the Blob exists entirely as a JavaScript object. But how do you display it in an <img>, play it in a <video>, or load it inside an <iframe>?

You can’t simply write:

img.src = blob; // ❌

because HTML elements were designed long before the File API existed. They know how to load resources from URLs, not JavaScript objects.

Rather than redesign every browser API, browsers introduced Object URLs.

const url = URL.createObjectURL(blob);
img.src = url;

An Object URL is simply a temporary identifier that points to an existing Blob.When an HTML element receives this blob: URL, it asks the browser to resolve it. The browser looks up the URL in its internal Blob registry, finds the associated Blob, and streams the data directly to the element. No network request is made—the bytes never leave your machine.

Object URLs are essentially a bridge between the JavaScript world and the browser’s resource loading system.

Blob Lifecycle & Garbage Collection

Although Blobs behave like normal JavaScript objects, there’s one important difference once you create an Object URL.Normally, a JavaScript object is cleaned up automatically when nothing references it anymore. However, creating an Object URL introduces a second reference that’s managed by the browser rather than the JavaScript engine.

let blob1 = new Blob(["Flygon"]);
blob1 = null;


const blob2 = new Blob(["Pikachu"]);
const url = URL.createObjectURL(blob2); //creates a second reference

Even if JavaScript drops every reference to the Blob, the browser can’t immediately delete its data because an <img> or <video> might still be using the Object URL. The browser therefore keeps the Blob alive until that URL is explicitly revoked.

URL.revokeObjectURL(url);

Calling it tells the browser that the Object URL is no longer needed and can be removed from its internal registry. Once both the JavaScript references and the browser’s Object URL reference are gone, the Blob becomes eligible for cleanup.

In small applications, forgetting to revoke an Object URL usually isn’t noticeable because the browser eventually cleans everything up when the page is unloaded. However, in long-running applications—such as image editors, document viewers, or design tools—continuously creating Object URLs without revoking them can cause browser-managed memory to grow over time.

Conclusion

At first glance, Blob looks like a tiny interface with only a handful of methods. But behind that simple API lies a surprisingly sophisticated system. Browsers manage where the data is stored, expose efficient streaming and slicing primitives, and bridge decades-old HTML APIs with modern JavaScript through Object URLs.

Understanding these implementation details changes how you think about file processing. Instead of treating Blobs as “just files,” you start seeing them as immutable snapshots of binary data that browsers can move, stream, cache, and optimize independently of your code.