Three different things get sold as “offline”
The word covers a spectrum, and most of it is not what you think you are buying. Know which one you are looking at before a deadline depends on it:
| Architecture | Where your image goes | Works with the network unplugged? |
|---|---|---|
| Cloud tool (upload-first) | Every file, to their servers. | No. The site itself won't even load. |
| Desktop app calling a cloud API | Every file — just from an app window instead of a tab. | No. The installer is a disguise, not an architecture. |
| “Offline-capable” PWA web tool | Depends on the vendor: the page is cached, but the model — or the image — often still travels. | Partly, and unpredictably. Test it. |
| Local inference (BatchBG, a few others) | Nowhere. Decode, segmentation, composite, PNG export, ZIP — all in your tab's memory. | Yes, after the one-time asset load. The whole point of this page. |
The distinction that matters on an actual airplane: a tool that needs the network only to arrive behaves completely differently from one that needs it on every file. In the second architecture a 300-SKU folder is 300 round trips that all fail the moment signal does; in the first, the disconnect is invisible. Our bulk background remover runs entirely in the fourth row — the same engine we documented down to the millisecond on the large-batch numbers page.
What actually crosses the wire here
Being precise, because vague privacy claims are how “offline” got its reputation. When you open this page: the HTML/JS comes down, the segmentation model comes down, and the WebAssembly inference runtime comes down — all once, all browser-cached after that, a few tens of megabytes total arriving at your machine. Anonymous pageview analytics go out — page URL and browser metadata, no file contents, no filenames, because the code that touches your images never holds them long enough to serialize them. That is the full conversation. Your pixels enter through the file picker and leave through the download button, and the only machine in between is yours. A tool that says “no upload” but phones home image bytes during “processing” is in row one or two of the table, regardless of the marketing.
The 60-second airplane-mode test (works on any tool)
Don't trust the copy; run the protocol: 1. Load your candidate tool once with internet. 2. Cut connectivity completely — airplane mode, or yank the cable, or block it in your firewall. 3. Process ten images you would never upload (a family photo, a scanned document). 4. Two verdicts: if it errors or silently queues them, it's not offline. If results appear, watch your router's live traffic list during the next batch — a genuinely local tool produces no image-sized payload, and any “local” tool that spikes on upload bandwidth is caught red-handed. This test audits desktop apps too, which is how several “private” installers have been shown calling cloud APIs underneath. BatchBG passes it by construction; so does the browser's own DevTools Network tab if you prefer a receipt over eyeballs.
When offline matters more than quality
The honest use cases, ranked by how much the disconnect saves you: Connectivity-dead jobsites — sellers photographing inventory in basements, markets, and rural listings with no stable broadband; load on the drive in, process on arrival. Travel days — a flight's four hours is exactly the shape of a 500-image catalog (see the time and memory math). Locked-down corporate or agency machines — networks that block outbound uploads outright; local processing isn't a preference there, it's the only path that runs at all. Vendor-outage insurance — when a cloud remover's API throws 502s during a launch push, a local pass doesn't move your deadline. Sensitive imagery — pre-release products, legal/medical documentation, client work under NDA, where the upload itself is the compliance problem, which is also why the same engine doubles as a read-only background screening QC gate.
The limits, stated plainly
This is a browser tab, not a native app, and two honest caveats follow. First, the network is needed for the first load of the session: assets must arrive before the lights go out, so build the two-minute load into your pre-flight routine rather than discovering it at 30,000 feet. Second, results live in the tab: browsers evict long-idle tabs, and an evicted tab means re-loading the page (online for that refresh) — which is why the working rule on big jobs is run a chunk, download its ZIP, then the next. Offline here means “works through the whole batch once loaded,” which is what the deadline-critical cases actually need — not a perpetual zero-network cold start. If you need a true zero-touch air-gapped install with no page load at all, a desktop app that bundles the model is the right tool, and we'll say so instead of pretending otherwise.
Frequently asked questions
Does BatchBG work with no internet connection?
Once the page and the model weights have finished loading, yes: the inference runs on your CPU and nothing is sent anywhere, so turning off Wi-Fi or switching to airplane mode after load does not stop the batch. What does need a connection is getting the page and model into the browser the first time — so plan a two-minute online window before the flight, the market stall, or the air-gapped office, load the tool once, and the rest of the session works dark.
What actually gets sent over the network when I use an offline background remover?
For a genuinely local tool, only two things ever cross the wire: static assets coming down (the page, the model file, the WASM runtime) and, in most analytics-enabled sites, anonymous pageview beacons. No pixel of your image leaves the tab, because the entire pipeline — decode, 320×320 segmentation, full-resolution composite, PNG encoding, ZIP packaging — runs in memory on your machine. Server-side tools are the opposite: every file is uploaded, processed remotely, and downloaded back, which is why they can meter you per image.
How do I verify a background remover is really offline?
Run the airplane-mode test with a folder you would never upload: disconnect after the tool has loaded, process ten images, and confirm the results come out. Then check your router's live connection list or a network monitor during the run — an honest local tool produces no image-sized upload. This works to audit any tool making the claim, including desktop apps that quietly call cloud APIs behind an install window.
Is offline processing slower than a server?
Per image it is comparable or faster once warm: on a modest two-core test machine we measured a median of about 0.5 seconds per image through this exact pipeline. Server tools add an upload and a download per file plus queue time, so for folders of hundreds of images the local path usually wins on wall-clock total — but the real difference is the failure mode: a local batch cannot stall on someone else's outage.
Why does the first load need internet if the images never leave my device?
Because the model travels to you, not your images to the model. The segmentation weights and the inference runtime are fetched once and sit in memory and the browser cache for the session. A desktop app ships the same weights inside the installer — that is the only architectural difference: an install versus a page load. Both end with the computation happening on your hardware.