Every background removal tool asks you to hand over a photograph. Most of them do not tell you what happens next, and the honest answer is that it depends entirely on which of three architectures the site is running — and you cannot tell which one by looking at the page.
Cutting out a product photo is harmless either way. Cutting out a photograph of a person, a document, or anything taken inside a client's premises is not the same decision, and it deserves about ninety seconds of checking before you click upload.
What removing a background actually requires
Background removal is not a simple filter. Separating a subject from its surroundings means recognising what the subject is — that this region is hair, that this is a shoulder, that this faint edge is part of the product and not part of the wall behind it.
Getting that right needs a segmentation model. Models of that kind are large: tens of megabytes at minimum, and considerably more for the accuracy people expect from a modern cutout tool. Where that model runs is the entire question.
The three places the model can run
All three are in use today, and they have very different privacy consequences.
- In your browser tab. The model file is downloaded once and cached, then runs on your device using WebAssembly or WebGPU. Your photograph is read locally and never transmitted. The first visit is slower because of the download; every visit after that is fast and offline-capable.
- On the operator's server. You upload the image, a server runs the model, and a result comes back. This is the classic architecture, and it is the one that creates a copy of your file somewhere you cannot see.
- On a third-party API. The site uploads your image to a commercial vision service and returns the result. Two copies now exist, under two different privacy policies, and the site you are looking at may not be the party that decides how long either is kept.
There is nothing illegitimate about the second and third options. Running a segmentation model server-side is easier to engineer and works on old phones. But the difference matters, and it should be stated on the page rather than buried in a policy document.
How to check in ninety seconds
You do not have to take anyone's word for it, including this page's. Open the tool, press F12, and switch to the Network tab before you choose a file.
- Watch the request sizes. If a request the size of your photograph appears the moment you select it, the file is being uploaded. A small request is a settings object; a multi-megabyte request is your image.
- Pull the network cable after the page loads. Then remove a background. If it completes, the model is running locally. This is the most reliable test available and it takes ten seconds.
- Check the first-load behaviour. A local tool will download something large once — often twenty to eighty megabytes — and show progress. A server-backed tool will not, because there is nothing to download.
- Look for an offline notice or a model size indicator. Tools that run locally generally advertise it, because it is the only real advantage they have over a server-backed competitor.
What the server-side architecture exposes
If the file is uploaded, four questions follow, and most sites answer none of them clearly.
- Is it stored or streamed? A tool that processes in memory and discards immediately is materially different from one that writes to a bucket first. Both are common; only one is usually disclosed.
- For how long? "We delete after 24 hours" is a real commitment. Silence is not a promise of anything.
- Who else sees it? If the processing runs on a third-party vision API, your image is subject to that provider's retention and training policies, which the site may not even have read.
- What is in the metadata? A photograph straight from a phone can carry GPS coordinates accurate to a few metres. Uploaded files frequently keep their EXIF data intact, and it is rarely mentioned.
The cases where this actually matters
It is easy to treat this as an abstract concern. It is not abstract in four situations.
- Photographs of people. A headshot carries a face, which is biometric data under several privacy regimes, and the cutout is usually made for a public profile.
- Identity documents. Passport and visa photographs need their background removed to a specification, which means the file is both an image of a person and an official record of their identity.
- Client material. Product photographs taken under NDA, packaging not yet launched, or anything a client paid to keep private.
- Photographs with metadata you forgot about. Taken at home, on a date, with a device identifier attached.
Reducing your exposure, whichever tool you use
These measures are worth taking regardless of which architecture you end up using.
- Strip location data before uploading anything. If your tool does not do it, most photo editors will, and it is a one-step operation.
- Confirm the specific image needs the operation. A cutout of a generic stock photograph can be found rather than made, and the file never has to be handled at all.
- Prefer a local tool when the image is sensitive. The cost is one slower first load. That is a small price for the file staying on your device.
- Refuse to upload things you would not email. It is a crude rule and it is surprisingly effective.
The background remover runs its model in the browser tab and processes the image on your device, so the file is never sent anywhere — which is why the first visit is slower and later ones are not. That distinction, working locally versus working remotely, is the one worth establishing before you hand over a photograph. The longer explanation of how local tools work covers the underlying browser capabilities, and the same test works on every other tool you use.