Most background removers do their work on someone else's computer. You upload an image, a server processes it, and a few seconds later you get a transparent PNG back. That round-trip is invisible enough that the question rarely comes up: should the image have left your device at all?
remove-bg.io runs the cutout in the browser by default. The image is processed on the same machine that loaded the page — phone, laptop, or desktop — and the bytes never travel to a server unless you explicitly opt into the cloud fallback. This piece is about what that choice unlocks, where it falls short, and the small set of cases where the cloud is genuinely the right tool.
This is not a "cloud is always wrong" argument. It isn't. The honest version of the story has trade-offs, and there are images and workloads where shipping the file off to a hosted GPU is the better answer. The defaults still matter, though, and they should default to keeping the image local.
What "on-device" actually means here
The cutout model — a quantized U-Net variant compiled to ONNX, run through WebAssembly — is downloaded once when you first open the editor, cached in your browser, and reused on every subsequent image. After the first load, there is no further network traffic for the cutout itself. The model is hosted at models.remove-bg.io and the cached file is preserved across browser cache clears (the service worker treats it as a separate, sticky cache).
When you drag an image in:
- The pixel data goes into a
Uint8Arrayin the page's memory. - The ONNX runtime, running in a Web Worker so the main thread stays responsive, runs the matte prediction.
- The result is composited onto a
<canvas>and made available as a PNGBlob. - Nothing in steps 1–3 touched a network socket.
If the local browser can't load the model — older devices, very low memory, or a sandboxed environment that blocks WebAssembly — the editor falls back to a hosted U2-Net inference at the API. That fallback is opt-in by default and is logged transparently in the network panel; no image leaves the device silently.
Privacy: the image stays where it started
This is the part most people care about and the part the cloud tools don't talk about much.
Every cloud-only background remover, by definition, takes a copy of your image. Most retain that copy at least temporarily — minutes to days — to support retries, billing, abuse detection, and model improvement. Vendor terms vary on whether your image can be used for training; some explicitly opt you in unless you opt out. Even with the most careful vendor, the image has now been transmitted across the public internet, decrypted at the edge of the vendor's network, written to at least one disk, and processed in shared infrastructure.
For a stock product photo, that's fine. For a copy of a passport, an internal product roadmap screenshot, a private family photo, a not-yet-public design comp, or a client's medical-record image, "fine" is a much higher bar.
On-device removal sidesteps the question entirely. The image isn't on a server because it was never sent to a server. There is no copy to delete, no log to review, no breach to disclose, no opt-out form to find.
For sensitive image types — passport and ID photos, anything under NDA, medical or legal documents, internal-only product material — local processing is the only option that survives a serious threat model. The fact that you don't have to trust the vendor is the feature.
Speed: no upload, no queue
The slowest part of a cloud-based background remover is almost never the inference. It's the upload. A 4 MB phone photo over a typical home connection takes 5–15 seconds to send and another 1–2 seconds for the response, on top of however long the actual cutout takes on the server.
On-device, that round-trip simply isn't there. The image is already in browser memory the moment you drop it. On a recent laptop, a 12-megapixel image cuts in under two seconds. On a modern phone, 3–5 seconds. There is no queue, no rate-limit ceiling, and no server-side cold-start.
This compounds when you're processing more than one image. A batch of 50 photos through a cloud API serializes the upload and download steps for every file — and runs into the API's per-account concurrency limits. The same batch, run locally with bulk processing, pipelines through the model as fast as the device can run it. On a recent MacBook, that's 15–25 cutouts per minute end-to-end, with no upload bandwidth wasted.
Offline: airplanes, train tunnels, conference Wi-Fi
The tool that won't load is worse than the tool that's a bit slower. Cloud-only background removers are unusable the moment your connection drops or the vendor's API has an incident.
Once the model is cached locally, the on-device path keeps working with no network at all. You can open the editor on a flight, in a basement office, or behind a hotel captive portal that blocks the API host, and still drop an image in and get a PNG out. The service worker keeps the page itself servable offline, and the model cache survives for as long as the browser keeps the cache alive.
This isn't a daily concern for most people. It is a daily concern for travelling photographers, field reporters, anyone working from a location with bad network, and anyone whose laptop has ever decided to "save data" on a hotspot. When the path that matters most is the one that works at 30,000 feet, on-device wins by being available at all.
Cost: nothing meters per image
Cloud-based background removers all share the same shape of pricing: free tier, then per-image or per-credit billing once you cross a threshold. The numbers vary — see our comparison of free background removers for current 2026 figures — but the basic structure is consistent. The 51st image of the month costs more than the 50th.
Local inference doesn't have that gradient. Once the model is downloaded (a one-time ~50 MB transfer, less if your browser already cached it from a previous visit), every cutout is free for as long as your device has electricity. There is no per-image cost to budget for, no quota to track, no dashboard to log into to see how close you are to the limit.
For a hobbyist removing a few backgrounds a month, this difference is invisible. For a small e-commerce operation cutting 500 product shots a season, it's the difference between a $40–$200 monthly bill and zero. For a designer running a one-shot client project at 2,000 images, it's the difference between a $400 surprise and an hour of unattended local processing.
When cloud genuinely wins
This is the part that gets skipped in tool-comparison posts that exist to push you toward one answer. Cloud has real wins, and a thoughtful tool offers both paths and lets you pick.
1. Very large batches with non-uniform images. If you're processing 50,000 mixed images and you need them all done in the next hour, your laptop's GPU is the bottleneck — not the network. A hosted GPU farm finishes the job in minutes. The break-even is around the low thousands of images for most consumer hardware.
2. Low-end devices. A four-year-old budget Android phone running the model in WebAssembly is going to take 20–30 seconds per image. On the same image, a hosted GPU returns in under one second. The local path technically works, but the user experience is bad enough that the cloud path is the right default for that device class.
3. Highest possible quality on edge cases. The hosted models are larger than what fits comfortably in WebAssembly. For images with very fine detail — wedding-dress lace, blowing hair against a busy crowd, intricate jewelry filigree — the hosted model has a measurable accuracy advantage. The on-device model is good enough for the overwhelming majority of inputs; for the last 1–2% of difficulty, hosted wins.
4. Server-side automation. A workflow that takes a webhook, processes the image, and pushes it into a CMS without a human in the loop is by definition not running in a browser. That's an API call, and an API call is a cloud call.
For everything else — single images, small batches, day-to-day product staging, social posts, screenshots, family photos — the on-device path is the better default. remove-bg.io ships both, runs the local path by default, and falls back to the cloud only when the device can't keep up or the user explicitly asks for it.
What to look for in an on-device tool
If you're evaluating in-browser background removers (this one or any other), the questions worth asking:
- Where does the model run? Look at the network panel during a cutout. If you see a multi-megabyte image upload to a third-party host, the cutout is happening in the cloud regardless of what the marketing copy says.
- Where is the model cached? A model that re-downloads on every visit isn't really local — it's a cloud dependency with a slow start. The right answer is a service-worker-backed cache or the browser's HTTP cache with a long max-age.
- Does the offline path actually work? Disconnect your network and try to drop a new image in. The honest answer is sometimes yes, sometimes no — and now you know which tool is which.
- What's the worker model? Inference on the main thread blocks scrolling and animations. The right architecture runs the model in a Web Worker so the UI stays responsive while a 12 MP image is being processed.
The remove-bg.io editor is built around all four answers being yes. The model lives in a worker, caches in a sticky service-worker cache, runs without network after first load, and falls back to a transparent hosted path only when the device honestly can't run the local one.
The default that matters
Defaults shape behavior. A tool that uploads by default, with a hidden setting for local processing, will upload your image essentially every time. A tool that runs locally by default, with an opt-in for the cloud, will keep the image on your device essentially every time.
The privacy story, the speed story, the offline story, and the cost story all point in the same direction: the cutout should happen on the device that has the image, not the device on the other end of an upload. The cloud earns its place for a specific set of jobs — large batches, low-end devices, the very hardest edges, server-to-server automation. For everything else, the local path is faster, cheaper, more private, and works on a flight.
If you've been using a cloud-only tool out of habit, drop an image into the editor and watch the network panel. The bytes don't leave. That's the whole pitch.
→ Open the editor | Help & guides | Bulk processing | Make a transparent PNG