Your photo stays on your device

What your browser downloads, and nothing else

Opening the background remover downloads the page itself, its styles, scripts, and images, all from this site. The engine and the AI model are not part of that: the page starts them only after you pick an image, so a visit that never picks one downloads neither.

On your first image, the browser fetches the engine (11.3 MB for the CPU build, 22 to 25 MB for the graphics-card builds) and the AI model (about 176 MB, in parts smaller than 25 MB). Each model part is checked against a SHA-256 fingerprint before use, so a damaged download is rejected instead of being used. Before loading the engine, the page also sends small HEAD requests (they ask whether a file exists without downloading it) to see which engine build is available. The sample photo is downloaded only if you click Try a sample photo.

Every one of these requests is a GET or HEAD to this site. Neither kind carries a body, the part of a request that would hold an uploaded file.

What stays in your browser afterwards

After the first image, your browser keeps the verified model parts in Cache Storage (a storage area each website gets in your browser), under the name backgrounds-remover-model, with a small note that all parts are saved. They hold only the model, never your images, and they are the reason later visits skip the 176 MB download. To remove them, clear this site's data in your browser; the next image then downloads the model again. A browser can also clear them on its own when the device runs low on space, and Safari does so for a site you have not used for a while; the model then downloads again with the next image.

While you work, your photo's preview and the result exist only as temporary blob: links inside the open tab. The page releases the old links whenever it makes new ones (for a new image, or a new background, size, or format), and the browser discards the rest when you close the tab. Apart from the model, the page's scripts store nothing: no cookies, no localStorage or sessionStorage, and no IndexedDB.

The page can read only the file you give it

You hand the page a file by choosing it, dropping it on the page, or pasting it. A web page cannot browse your photo library or your folders: the browser gives it only the files you picked (one, or several for a batch) and nothing else. It never asks for the camera, and the site's headers switch the camera off anyway.

Your browser's own image decoder, the same one that shows pictures on any website, turns the file into pixels inside a Web Worker (a background thread of your tab). From then on the page works only with those pixels. Nothing inside the file is run as code, and a file that is not an image is refused with a message.

What the browser enforces

The site sends security headers with every page, and your browser enforces them no matter what the page's scripts try to do. In plain language:

Behind the headers, the site is a set of static files on a content delivery network. The only server code is a small function that receives the error reports described below at /api/error: it reads at most 8 KB of text, keeps a fixed list of fields, and drops the rest, so there is no endpoint that could accept an image even if the page tried to send one. You can read the headers yourself: in the Network tab described below, click the page's first request and look at its response headers.

Check it yourself

Your browser's developer tools list every request a page makes, so you can check all of this on your own computer (Chrome's Network panel guide explains the panel):

1. Open the background remover on a computer and press F12 (or Cmd+Option+I on a Mac) to open developer tools, then choose the Network tab. In Safari, first turn on the developer features in Settings, Advanced.
2. Reload the page. You should see the page, its styles, scripts, and images, all from backgrounds-remover.online, and nothing from the engine or the model yet.
3. Pick an image. New rows appear: the page's worker script, one or two HEAD requests, the engine's .mjs and .wasm files, a small .json manifest, and the model parts, files under /engine/model/ whose names end in .part000, .part001, and so on.
4. Check the Method column (if it is hidden, right-click a column header to show it). Every row should read GET or HEAD, and every address should be backgrounds-remover.online. Rows starting with blob: or data: are links inside your tab, not network transfers.
5. Remove a background from a second image in the same tab. No new engine or model requests appear, because the engine is already running in your tab. On a later visit, picking an image requests the engine files and the manifest again, but no model parts.

An upload looks different: a request with the POST or PUT method whose size is about the size of your photo, often to another domain. If you ever see one when you pick a photo here, something is wrong, and we want to hear about it at support@backgrounds-remover.online.

A POST request can appear only when something fails, including when the graphics card cannot start the model and the page switches to the processor: an error report of at most a few kilobytes of text (no more than ten per page view) sent to this site's own /api/error, described below. It holds no part of your photo, its name, or the result.

What our automated test checks

An automated browser test loads a built copy of the site and removes a real background with the real engine. Every change to the site runs it in Chromium, the engine behind Chrome and Edge, and a failure stops the deploy. On September 27, 2026, the same test, with every check listed below, also passed in Firefox and in WebKit, the engine behind Safari; we ran those two by hand, and they are not part of every deploy. Among its checks:

• A plain visit loads no worker, no engine, and no model.
• After a background is removed, no request has left the site's own address. The only other addresses are blob: and data: links inside the tab.
• While a background is removed, every request to the site is a GET or HEAD with no body, so nothing is uploaded; the only POST the test allows is an error report to /api/error.
• A return visit in the same browser loads the model from the device and requests no model part.
• Switching to a white or colored background makes no new request to the engine.
• When the engine cannot load, the page sends exactly one error report to this site's own address, with no file name or image data in it.

No ads, no analytics, and error reports only when something fails

This is a separate promise from "no upload", with its own evidence. The site shows no ads, sets no cookies, and loads no analytics script, so no script reports your visits or clicks to anyone. Its code includes an analytics layer that could count the tool's steps, but no provider is attached, so it sends nothing. What the site does send is an error report when its own code or the background remover fails, for example when the browser runs out of memory or the graphics card cannot start the model. The report goes to this site's own address and carries the kind of failure, the page path, your browser's user-agent string, and the site's version, never your image, its file name, or the color you picked. The privacy policy lists every field and how long reports are kept. The open-source software the tool is built on is listed on the open-source credits page.

Other background removers handle photos differently. The guide are online background removers safe quotes what upload-based services say they keep and ends with a checklist for vetting any tool. For the model, the engine builds, and the measured speed, see how Backgrounds Remover works.