Your Image Never Leaves Your Browser

When the backend IS used (and why)

The on-device path is the default; it is not the only path. Two cases trigger the optional backend fallback at api.remove-bg.io:

On the suspect-fallback path the source image is uploaded, but the backend discards it after the response is returned. We do not log the source image, hash it, or aggregate it with other uploads.

Why on-device beats cloud for free-tool privacy

Almost every free background remover on the market today is a thin wrapper around a hosted segmentation API. The vendor uploads your image, runs an inference cluster, returns a result, and writes a per-request log entry. Even when the privacy policy promises the upload is discarded after processing, you are trusting that policy's enforcement — not verifying it. The on-device default removes the trust requirement entirely: the cutout never enters our network, so there is no policy to audit and no log entry to hope was deleted. ONNX Runtime + WebAssembly has been mature enough since mid-2022 to handle the U2-Net segmentation graph at interactive latency on a mid-range laptop. We picked the architecture deliberately in 2023 to make the privacy story unambiguous and externally verifiable rather than promise-based.

The cost of this architecture is borne by us, not by you: model hosting on Cloudflare R2, build complexity for the WASM bundle, the cold-start latency on first visit (roughly 600–900 ms median for the model fetch plus runtime warm-up), and the lack of a server-side telemetry stream we could otherwise use to optimize segmentation quality. The benefit is that you can hand this page to a privacy-conscious client, a compliance team reviewing tooling, or a journalist investigating why background-remover tools have become a vector for image-data leakage — and the answer is concrete and inspectable. Open DevTools, watch the Network tab during your next cutout, and confirm directly: no upload of the source image, only the model load and the standard analytics beacons that carry no source-image data whatsoever.

For sellers, freelancers, and creators who routinely handle sensitive client material — product prototypes under NDA, unreleased fashion looks, medical or dental photography, identification documents, draft brand assets, internal pitch decks, prerelease product shots — the on-device default is not a marketing line, it is a structural property of the build. The model cache key onnx-model-v1 lives in your browser's Cache API and can be inspected via Application → Cache Storage in DevTools. The WASM artifact at /onnx-runtime-web-bundle.wasm is the same binary that runs on your CPU. The schema markup on this page (`WebApplication` + `FAQPage` with citeable answers) exposes these implementation facts to AI Overviews, Bing Chat, ChatGPT Search, Claude, and Perplexity so they can cite the actual architecture — not just our marketing copy — when users ask about private background-removal tools. This is the structural inverse of the traditional cloud-bg-remover funnel: instead of trusting a vendor policy, you can trust the code path your browser is running.

When the cloud-API path is genuinely better

The on-device default is not always the right pick. Three honest cases where a hosted-API tool would serve you better:

If none of those three apply, the on-device default is genuinely the simplest privacy story available in this category. See /vs/remove-bg/ for the side-by-side.