What On-Device Processing Actually Means

The usual arrangement, and why it is normal

The conventional way to build an image tool is to send the file to a server, run the model there on hardware you do not have, and send the result back. It is a sensible design: the model is large, servers are fast, and the developer keeps control of the model.

The cost is that your image sits, at least briefly, on a computer belonging to someone else. Even with an honest operator and a stated deletion policy, the file has been transmitted, has passed through intermediaries, and exists in logs and caches you cannot inspect. For a photo of a coffee cup this does not matter. For an unreleased product, a document, a signature, or a photograph of a person, it is a real decision rather than a formality.

None of this makes server-side tools wrong. It makes the distinction worth knowing, because the two designs fail in completely different ways.

What this tool downloads

On-device processing does not mean nothing crosses the network. It means the traffic goes the other way: instead of sending your image out, the tool brings the model in.

On first use, the browser downloads two things. One is the neural network itself — the ISNet segmentation model that decides which pixels are subject and which are background. The other is the runtime that executes it: ONNX Runtime Web, compiled to WebAssembly, with a separate build for browsers that support WebGPU acceleration. These runtime binaries are served from a public package CDN, which is why the download can be tens of megabytes on first load.

That download happens once and is then cached by your browser. Every subsequent image is processed with no network activity related to the removal at all — which is also why the second image you process is noticeably faster than the first.

The image itself is never part of any of this. It is read from the file you selected into the page's own memory, passed to the model running in your browser, and the result is drawn onto a canvas. There is no upload step because there is nothing to upload to.

How to verify it yourself

You do not have to take this on faith, and the check takes about a minute. Open your browser's developer tools — F12 on Windows, Option-Command-I on a Mac — and select the Network tab.

Load the page and process an image while the Network tab is recording. You will see the page's own files, then the model and runtime downloads on first use. What you will not see is an outbound request carrying your image: no large POST or PUT request appearing at the moment you press the button.

Reload the page and process a second image with the Network tab still open. This time the removal produces essentially no traffic at all, because everything needed is already cached locally.

For a stronger test, load the page, then disconnect from the network entirely and process an image. Once the model is cached, removal works offline. A tool that uploads cannot do that, and this is the most direct demonstration available.

What this does and does not protect

What it protects: your image is not transmitted, not stored on a server, not retained in a processing queue, and not available to be used as training data, because it never leaves the machine you are sitting at. For sensitive images — documents, signatures, faces, unreleased work — this removes the entire category of risk that comes with handing a file to a third party.

What it does not do: it does not hide the fact that you visited the site. Loading a page means your browser contacted a web server and a CDN, and those see ordinary request metadata such as an IP address, exactly as they would for any website. This site also uses standard web analytics on page visits and may serve advertising, both of which are described in the privacy policy.

It does not protect the image from your own device. A file on your computer is still a file on your computer, subject to whatever else has access to it. If you download a cut-out to a synced folder, it syncs.

And it does not make the image anonymous. Removing a background does not remove metadata from the original file, and the resulting PNG is still a picture of whatever it is a picture of. On-device processing is about who else sees it, not about what it contains.

The trade-offs of doing it locally

The first run is slower. You are downloading a model instead of borrowing one already loaded on a server, and that is a real wait on a slow connection. It happens once per browser.

Speed afterwards depends on your hardware rather than a data centre's. A recent laptop with WebGPU support processes a large image in a few seconds; an older phone takes noticeably longer and uses a lot of memory. On very large images, a phone can run out of memory entirely, which a server would not.

There is no history and no account. Nothing is saved anywhere, which is the point, but it also means a result you did not download is gone when you close the tab. Download before you navigate away.

And the model is fixed at whatever was downloaded. Server-side tools can swap in an improved model silently; here you get whatever version the page ships, which is more predictable but not automatically the newest thing available.

When this matters enough to choose it

For most photos it genuinely does not. A picture of a chair does not need protecting, and any reputable tool will do.

It starts to matter when the image is one you would hesitate to email to a stranger: a product that has not launched, a scan of a document, a signature, a photograph of a child, medical or legal material, or anything covered by an agreement about where data may be processed.

It also matters in the ordinary organisational sense. Plenty of workplaces have rules about uploading company material to third-party services, and a tool that does not upload is straightforwardly compliant with them rather than a judgement call.

If you are unsure, apply a simple test: would you be comfortable if this file appeared in a log you cannot see? If not, use something that never sends it — and verify with the Network tab rather than trusting a claim, including this one.