2026-08-03
Do you have to trust a background remover with your photo? What running entirely in the browser actually changes
Search "is remove.bg safe" or "사진 배경 제거 앱 안전한가요" and you'll find people asking a question that has nothing to do with output quality: what actually happens to the photo after you hand it to a background-removal tool? For most photo-editing tools — including well-run, security- audited ones — the honest answer is "it's sent to a server, processed, and deleted fairly quickly, according to a policy you're trusting them to follow." That's a genuinely different category of answer from "it never left your device in the first place." Here's what a responsible cloud tool actually discloses about that process, why the underlying trust question has become a live public concern well beyond background removal specifically, and exactly what changes, architecturally, for a tool like NearBG that runs entirely in the browser.
What a well-run cloud tool actually discloses
remove.bg is a useful example here precisely because its own privacy documentation is specific and reasonable, not vague. Fetched directly from remove.bg's own pages: uploaded images and results are deleted "at the latest about one hour after the upload," and separately, "typically within 60 minutes, guaranteeing no retrieval of any past data after 90 days." Images aren't shared with third parties or published, transfers are SSL/TLS-encrypted, and remove.bg says it undergoes independent third-party security assessments, including OWASP-standard penetration testing. That's a legitimately careful policy — this isn't a case of a shady tool with no disclosure. But notice what kind of claim it still is: a written commitment about what happens after your photo has already left your device and reached a server you don't control. Whether that commitment was actually followed for any given upload isn't something you can verify yourself; you're trusting the policy, the audits, and the company standing behind them.
Why that trust question is on more people's minds right now
This isn't an abstract worry. In June 2024, Adobe updated its Creative Cloud Terms of Use with language allowing content access "through both automated and manual methods, such as for content review" — vague enough that creators read it as permission to train AI on their work, and the backlash was immediate and large (one social media post highlighting the clause reportedly drew over 5 million views and 50,000 likes). Adobe revised the terms on June 24, 2024, explicitly stating users retain ownership and promising not to use customer content to train generative AI models, Adobe Stock submissions aside. That episode has nothing to do with remove.bg or NearBG specifically — it's cited here only as real, dated context for why "what does this tool do with what I give it, beyond the one job I asked for" stopped being a fringe question for anyone who uses creative or photo tools. Once that question is live in people's minds, it applies to every tool that asks for an upload, not just the one that triggered it.
The on-device alternative: not a better answer to the trust question, a different question entirely
The broader on-device AI trend exists for exactly this reason, and it isn't limited to photo tools. As AhnLab — a Korean cybersecurity company, not a marketing blog — puts it: cloud AI carries security exposure because user data all gets sent to the cloud in the first place, while on-device AI's real advantage is that processing never leaves the device, which is why phones like Google's Pixel 8 Pro already run image compositing and removal features on-device rather than server-side. NearBG isn't using that same phone-NPU technology — it runs a segmentation model inside a browser tab via WebAssembly, covered in this blog's first post — but it shares the exact property that matters here: the photo is processed on the same device you're already using, and never becomes a file sitting on someone else's server, even briefly. That's not remove.bg's ~60-minute retention window done better; it's a different kind of guarantee. There's no retention window to disclose, because there's no upload event for a retention policy to apply to.
How this is actually enforced, not just promised
The important distinction: NearBG's "we don't upload your photo" isn't a policy statement asking
for trust the way a retention-and-deletion promise is — it's enforced by the browser itself. near's
Content-Security-Policy sets connect-src 'self', which technically blocks any network
request the page's code might try to make to anywhere other than the site's own origin. The
segmentation model and onnxruntime-web's own WASM runtime binary are both served same-origin for the
same reason (covered in this blog's first post) — not because a CDN would be slower, but because
fetching from one would either violate that CSP outright or require weakening it, and weakening it is
exactly the kind of silent capability-creep that would let an image-carrying request slip out later
without anyone having to lie about a policy. If the code tried to send the photo anywhere, the
browser — not a promise — would refuse the request.
When a policy-based tool is genuinely fine, and when zero-upload matters more
| Situation | What matters most |
|---|---|
| An everyday photo, low sensitivity, speed or output quality is the priority | A disclosed, audited retention policy like remove.bg's is a reasonable thing to trust — this post isn't arguing otherwise. |
| An unreleased product photo, a photo of a child, an ID or personal document, anything you'd rather not have exist on any server even for an hour | The architecture matters more than the policy's quality — there's a real difference between "we promise to delete it soon" and "there was never a copy to delete." |
| You simply don't want to have to read and evaluate a privacy policy for a one-off photo edit | An on-device tool removes the question rather than answering it well. |
Being precise about what this claim covers
Worth being exact here rather than overselling it: "your photo is never uploaded" is specifically about the image data going through NearBG's background-removal step — that's the claim the CSP technically enforces, and it's the one this post is making. It isn't a claim that nothing on the page involves a server at all: NearBG shows ads to keep the tool free, and that ad delivery only activates after an explicit Accept on a separate consent gate — a different, disclosed system, unrelated to and never touching the photo you're editing.
The honest summary
remove.bg's own disclosed policy — delete within about an hour, encrypt in transit, get audited — is a reasonable, specific answer to "what happens to my photo," and this post isn't arguing it's unsafe. But it's still an answer that requires trusting a policy, because the photo did leave your device. Adobe's 2024 terms controversy is a real, separate example of why that trust gets tested in public, for tools that had nothing to do with the controversy itself. NearBG's answer to the same question is architectural rather than promissory: the photo is processed inside the browser tab you're already looking at, the same CSP that blocks any external request also blocks the photo from ever becoming an upload, and there's no retention window to ask about because there was never a transmission to retain.