Back to Background Remover

How to Remove Image Backgrounds Privately (No Server Uploads)

Every background-removal tool makes a privacy claim. Most of them ask you to trust a sentence on a marketing page: "your images are encrypted", "we delete uploads after one hour", "we never share your photos with third parties". None of that is checkable by you. It relies entirely on the company's word, and on nobody there making a mistake with a server log or a cache six months from now. There's a completely different kind of claim, which is that an image never leaves your device at all. That one you can verify yourself, in about thirty seconds, with tools already built into your browser. This page shows you how, so you're not taking anyone's word for it, including ours.

The thirty-second check

Open your browser's developer tools before you upload anything. In Chrome, Edge or most Chromium browsers, press F12 or right-click the page and choose "Inspect", then click the "Network" tab. In Safari, open Settings > Advanced and turn on "Show features for web developers", then use the new Develop menu: Develop → Show Web Inspector → Network. In Firefox, press F12 and open the Network tab.

Before you drop anything in, know what's already normal in that panel: every page here loads two font files, from fonts.googleapis.com and fonts.gstatic.com, as soon as it opens, consent or not. If you accepted the cookie banner, you'll also see requests to Google's and Microsoft's analytics and advertising domains. None of that is your photo. What you're checking for is narrower: whether any request, at any point, carries a body roughly the size of your image.

Leave the panel open, then drop in a photo. Here's what to look for:

• A request with a large size. Sort the Network tab by size if you can. Your photo is probably a few hundred KB to a few MB. If some request in that list is roughly that size and it's going out (not coming in), that's your image leaving.
• The request method. Click any suspicious request and check its method and headers. An image upload is almost always a POST request with a Content-Type: multipart/form-data header, because that's the standard way browsers send file data to a server. If you see a POST with a multipart body and its size roughly matches your photo, the image is being uploaded, whatever the marketing copy says.
• Where the request goes. Look at the domain in the request URL. Some tools tell you images are processed "securely" while quietly sending them to a third-party API on a completely different domain than the one you're visiting.

On this site, try it now. Open the Network tab, drop a photo onto the tool on the homepage, and watch while the background disappears. The one large transfer you'll see happens only the first time you use the tool: about 65MB, made up of the 44.3MB ISNet segmentation model plus the 23MB ONNX Runtime WebAssembly binary that runs it. Both are cached afterwards. Neither carries your photo; they're the code and weights, fetched once. What you won't find is a POST request with a body roughly your photo's size, because there isn't one. Push the check further yourself: finish one background removal while online, then disconnect entirely and remove a background from a different photo. It still works, because there's nothing left to send. For the full setup, including installing the app for offline use, see removing backgrounds with no internet connection.

"We delete it after an hour" is not the same claim

Three phrases get used almost interchangeably in privacy pages, and they promise very different things.

• "We delete your images after 24 hours" means your image was uploaded, sat on their server for up to a day, and was (they say) then deleted. During that window it existed on infrastructure you don't control: potentially logged, cached, backed up, or swept into an error report. Deletion after the fact is a policy enforced by process, not architecture, and policies can lapse, be misconfigured, or simply not apply to backups.
• "We don't use your images for training" is a promise about downstream use, not about whether the image was transmitted and stored in the first place. It says nothing about server logs, CDN caching, or subprocessor access.
• "Your image never leaves your device" means there is no upload step to begin with. Nothing to delete later, because nothing was sent. This is an architectural fact, not a retention policy, and it's the one you can confirm yourself with the Network tab check above.

Who this actually matters for

There are situations where it genuinely matters which kind of claim you're relying on:

• Client work under an NDA. If you're a designer or photographer editing product shots or portraits under a confidentiality agreement, an upload-based tool creates exactly the situation those agreements exist to prevent: a copy of the file on a server you don't control, even briefly. Because the editing step here involves no transfer at all, there's no such copy to account for. Whether that satisfies your agreement's specific wording is a question for whoever wrote it, not for this page.
• ID and passport photos. Government ID photos, passport applications, visa photos: exactly the kind of image where "which third-party server briefly had a copy of my passport photo" is a question you'd rather not have to answer at all.
• Unreleased product shots. If you're prepping images for a launch that hasn't happened yet, an upload to any external server, however reputable, puts a copy of unreleased material outside your control before the embargo lifts.
• Photos of children. Many parents are, reasonably, more cautious about images of their kids than anything else. Not uploading sidesteps the question of what a service's retention and access policies actually mean in practice.
• Anything covered by an employer's data policy. If your employer restricts uploading customer or internal images to unapproved third-party services, a local, in-browser tool may sit outside that restriction in a way an upload-based one doesn't. Check your own policy to be sure.

None of this is a claim that this tool is certified, approved, or compliant with any particular regulation. We make no GDPR, HIPAA or CCPA compliance claim, and "processed locally" is not a substitute for reading whatever rules actually apply to your situation. What changes here is narrower: there is no upload step, so a third-party server never holds even a temporary copy of your file.

What about the analytics and ads on this site

This site can also load Google Analytics, Microsoft Clarity and Google AdSense, which raises a fair question: doesn't that contradict everything above? No, because the two systems are unrelated and one of them is optional. The cookie banner on arrival controls whether any of those three scripts load at all. Decline it and none of them run, on this page or anywhere else on the site, and the editor works identically either way. The background-removal code has no upload path regardless of your consent choice; analytics and ads are layered onto the same domain, not something the tool depends on. If you're specifically here for the privacy properties, decline the banner and re-run the Network tab check above.

A limitation worth stating plainly

The verifiability here has a boundary: it covers the editing step, not the browser or the machine it's running on. If your device already has malware capturing screenshots or reading the clipboard, no client-side architecture protects you, and that's true of every tool, local or cloud. What in-browser processing removes is the specific, common risk of a file transiting and residing on infrastructure you don't control, purely to have its background removed. That's a real and checkable improvement. It isn't a guarantee about the security of your own computer, and no honest tool should claim otherwise.