How Background Removal Runs Entirely in Your Browser

Almost every background remover you have used works the same way: your image is uploaded to a server, a model runs on that server's GPU, and a result comes back. nobackground does none of that. The model runs inside the browser tab you already have open, on your own CPU, and the image never leaves your device. This post explains how that pipeline actually works, because the architecture has consequences for privacy, for speed, and for the kinds of images it handles well.

The short version of the pipeline

1. You select an image. It is read into memory as a blob; no network request is made with it.
2. A segmentation model is loaded, or reused from the browser cache if you have used the tool before.
3. The image is resized to an inference-friendly resolution and handed to the model inside a Web Worker.
4. The model returns a mask: a greyscale image where brightness represents how likely each pixel is to be part of the subject.
5. We refine that mask, then composite it back onto the original full-resolution pixels and export a PNG with an alpha channel.

Steps three through five are where most of the interesting engineering lives, and where the difference between a usable cutout and an obviously machine-made one is decided.

Running a neural network without a server

The segmentation model is an ONNX model executed through a WebAssembly runtime. WebAssembly is a low-level bytecode format that browsers execute at close to native speed, which is what makes running a model of this size locally practical at all. The model weights are static files, so after the first run your browser caches them exactly as it caches any other asset; a second visit skips the download entirely and processing starts almost immediately.

All of this happens in a Web Worker rather than on the main thread. That detail matters more than it sounds: inference on a large image takes seconds, and if it ran on the main thread the entire page would freeze, scrolling and all. Pushing it into a worker keeps the interface responsive and lets us report real progress while the model is still running.

Why we run two different models

There is a genuine tradeoff between a full-precision model and a quantized one. The full-precision variant produces better edges, particularly on hair and fine detail, but it is slower and uses more memory. The quantized variant stores its weights at reduced precision, which makes it substantially faster and lighter at a small cost in edge quality.

Rather than asking you to choose, we pick based on the file you dropped in. Images under roughly 2.2 MB get the full-precision model, because they process quickly enough that the extra quality is free from the user's point of view. Larger files get the quantized model, because on a mid-range laptop the full-precision path on a 12-megapixel photo can push past the point where the wait feels broken rather than slow. It is a pragmatic rule rather than an elegant one, and it reflects the constraint that we are borrowing your device's CPU rather than renting a server GPU.

Inference resolution versus output resolution

Segmentation models are trained at a fixed input size, and feeding them a much larger image does not improve the result; it mostly costs time and memory. So before inference we scale the image so its longest side lands in a band between roughly 960 and 1400 pixels. That is the resolution the model actually sees.

The important part is what happens next. We do not export the model's output. We take the mask it produced, scale it back up to the original image dimensions, and apply it as an alpha channel to the untouched original pixels. Your 4000-pixel product photo comes back as a 4000-pixel transparent PNG, with every bit of the original colour and detail intact, because the model was only ever asked to decide which pixels to keep, not to redraw them.

This is a meaningful distinction when comparing tools. Some services return an image at the model's working resolution, which means you silently lose sharpness even when the cutout itself is accurate. Checking the pixel dimensions of a downloaded file against the original is a fast way to find out which kind of tool you are using.

Turning a rough mask into a usable edge

A raw model output is not directly usable. It typically has soft, uncertain values in a band around the subject, occasional isolated specks of false positive far from the subject, and edges that are either too hard or too mushy depending on the image.

Our refinement pass does a few specific things. It applies a smooth threshold curve rather than a hard cutoff, centred around the middle of the mask's value range, so that genuinely ambiguous pixels keep partial alpha instead of being forced to fully opaque or fully transparent. This is what preserves the look of hair, fabric fringe, and soft shadows. It also cleans up isolated specks, and it treats very low alpha values as fully transparent so that the exported PNG does not carry a faint ghost of the removed background across large empty regions.

The white background special case

One image type gets its own treatment: products photographed on a white sweep or a white table. This is by far the most common e-commerce setup and also one of the hardest, because the boundary between a light product and a white background is genuinely ambiguous at the pixel level.

Before compositing, we sample the pixels along all four borders of the image and compute their average brightness and saturation. If the border is consistently bright and close to neutral, we treat the image as a likely white-background shot and contract the mask by one pixel. That single pixel is the difference between a clean cutout and one with a pale rim that becomes visible the moment the product is placed on a coloured page. It costs an imperceptible amount of the subject and removes the most common visible defect in this category.

What this architecture is good at, and what it is not

The advantages are concrete. Your image is never transmitted, so there is no server-side copy to worry about, no retention policy to read, and nothing to breach. There is no per-image cost, so there is no reason to meter you. And after the first load the tool works offline, because everything it needs is already cached in your browser.

The constraints are equally real, and worth stating plainly. Processing speed depends on your device, so an older phone will be noticeably slower than a current laptop. The first run requires downloading model files, which is a one-time cost but a real one on a slow connection. Memory limits mean extremely large images have to be handled carefully. And we cannot ship a model the moment a better one is published, because model size directly affects how long your first visit takes; a server-side service can swap in a larger model without its users noticing, and we cannot.

Those tradeoffs are the honest version of the pitch. On-device processing is not universally better; it is better when privacy, cost, and offline capability matter to you, and it asks you to spend a few seconds of your own hardware in exchange.

Verifying the privacy claim yourself

You do not have to take any of this on trust, and you should not. Open your browser's developer tools, switch to the Network tab, and process an image. You will see the model files download on the first run and nothing image-shaped go out after that. For a stronger test, load the page, then disconnect from the network entirely and process an image; if it completes, the processing was demonstrably local. That test takes thirty seconds and it works on any tool making a similar claim.

Quick recap

The pipeline is: read the file locally, load a cached ONNX model into a WebAssembly runtime inside a Web Worker, run inference at a controlled intermediate resolution, refine the resulting mask with a soft threshold and a white-background correction, then apply that mask as an alpha channel to the original full-resolution pixels. Nothing in that sequence involves a network request carrying your image, which is the entire point, and it is verifiable in your own browser in under a minute.