Can a background remover really work with the internet off?

Two questions hiding inside one question

People ask whether a background remover works offline and mean three different things: does my file get uploaded, does the page work with no connection at all, and does it matter which way it goes. Those have three different answers and only the first one is a clean yes.

The upload question is the one with a privacy consequence, so it is worth answering with something you can check rather than a promise. The no-connection question is the one vendors overclaim on, because almost every browser tool has to fetch its engine at least once. The does-it-matter question is the one nobody asks, and it turns out to have the largest number in it.

So we will take them in that order, and every figure below is either read out of our own source or computed from measurements published earlier on this site.

What is actually in the source

A claim about not uploading is only worth something if you can verify it, so here is the complete network surface of this site. There are four fetch calls in total.

• Two of them download the tool itself. app.js fetches the gzipped ffmpeg core, 9.71 MB, from the same host the page came from, then decompresses it in the browser with DecompressionStream. That is a download, not an upload.
• The third only fires if you ask for it. If you paste an https:// link into the URL box, the page fetches that file from wherever you pointed it, with a CORS check so a failure gives you a readable message. You typed the address, so you decided where that request goes.
• The fourth is server-side plumbing. The worker fetches its own assets and its own 404 page. It never sees your pixels.

Just as useful is what is not there. Searching the source for XMLHttpRequest, WebSocket, navigator.sendBeacon, importScripts and axios returns nothing for all five. There is no beacon quietly reporting usage, no socket streaming frames out, no second worker phoning home.

The only external domains that appear anywhere are greenbackgroundremover.com itself for canonical and social tags, schema.org inside a JSON-LD block that is never fetched, and googletagmanager.com.

That last one deserves its own paragraph rather than a footnote. This site runs Google Analytics, and that tag does make a request to a third party on every page load. What it does not receive is your image or your video — nothing in the processing path hands pixels to it. But it exists, it is a request leaving your browser, and it would be dishonest to write a page about privacy while leaving it unmentioned.

The bill if this ran on somebody else's server

Now the part nobody puts on a pricing page. Suppose the same job were done in the cloud: you upload the clip, a server keys it, you download the result.

Using the measured file sizes from our export test, a ten second 1080p30 clip goes up as 2.2 MiB of source MP4. Coming back down, depending on the container:

• MOV with alpha — 2,300 MiB, which is 1,045 times the upload
• APNG — 1,230 MiB, 559 times the upload
• MKV — 430 MiB, 195 times the upload

The asymmetry is the whole story. Uploading is cheap because H.264 is good at compression. Downloading is expensive because a transparent video cannot use it — alpha has to stay lossless, and lossless video is enormous. That is the same finding as our export size test, arriving from the opposite direction.

There is a second version of this bill that is even less flattering. If a service needed the raw pixels rather than your compressed file, ten seconds of 1080p30 is 300 frames of RGBA at 8,294,400 bytes each — 2.32 GiB before a single byte of compression. That is how much data your machine moves through its own memory when it processes locally, and none of it travels anywhere.

The expensive direction is down, not up

Putting times against those sizes makes the asymmetry obvious. These are computed at a few common connection speeds, and to be precise about it: these speeds are assumptions, not measurements. This tool does not test your line and we are not claiming these are your numbers.

• At 100 Mbps — 0.2 seconds up, 3.2 minutes down
• At 50 Mbps — 0.4 seconds up, 6.4 minutes down
• At 25 Mbps — 0.7 seconds up, 12.9 minutes down
• At 10 Mbps — 1.8 seconds up, 32.2 minutes down
• At 5 Mbps — 3.7 seconds up, 64.3 minutes down

Look at where the zeros are. The upload column is seconds at every speed. The download column is minutes at every speed. Any service that keys video for you has to solve that download problem, and the usual solution is to give you a smaller file than the one you actually wanted — a premultiplied MOV at lower resolution, or an MP4 that has quietly lost its transparency. The convenience and the quality are in direct conflict, and the conflict is caused by bandwidth, not by engineering effort.

What local processing costs you instead

Running it on your own machine is not free. It just moves the cost from one column to another.

From the same export measurements, encoding ten seconds of 1080p as MOV costs about 29 seconds of CPU. As APNG it costs about 720 seconds, which is why nobody ships APNG for video. Meanwhile the keying itself runs in JavaScript over 2,073,600 pixels per frame at 1080p, and that part cannot be handed to a codec, because the codec only ever sees finished frames.

So the trade is: thirty seconds of your fan spinning, or thirty-two minutes of downloading at 10 Mbps, plus handing your unpublished footage to a server you do not control. On a fast connection the arithmetic gets closer and the privacy argument carries more of the weight. On a slow one the download alone settles it.

The honest limit: the engine is still a download

Here is the claim we will not make. This page does not work the first time with no connection at all, because the engine is not in the HTML.

The files sit in an assets directory that totals 21.62 MB, but you only ever pull the route you actually use. The video route downloads ffmpeg-core.wasm.gz at 9.71 MB, compressed, and unpacks it in the browser. The subject model route downloads a 5.43 MB wasm plus a 0.24 MB model file, about 5.67 MB together. Neither is small, and pretending otherwise would be the exact kind of overclaim this page is arguing against.

What happens after that first load depends on your browser. There is no service worker registered on this site, so whether the engine is still there next week is down to your own HTTP cache, not to anything we control. Claiming offline support we cannot guarantee would be worse than not claiming it.

One more thing we did not do: we did not run a real disconnect test. Every figure here comes from reading the source and from arithmetic on measured file sizes. If you want the empirical version, the next section tells you how to get it in about a minute.

How to check this yourself

None of the above requires trusting us. All of it is verifiable from the browser you already have open.

• Read the requests. Open DevTools, go to the Network tab, load the page and drop in a file. Filter to Fetch/XHR. You are looking for requests whose destination is not this domain. There should be none carrying your file.
• Watch the size of the biggest one. The engine download should be the largest single transfer, around 9.71 MB compressed for the video route. That is the tool arriving, not your footage leaving.
• Then actually pull the plug. Once the engine has loaded and cached, turn on offline mode in DevTools and process another file. If it still works, you have your own answer, measured on your own machine, rather than ours.
• Check the exports stay local. Nothing in the save path involves a request. The file is assembled in memory and written by the browser.

The third step is the only one that answers the question you probably came here with, and it is deliberately the one we are asking you to run instead of us.

Related questions

Open the green screen remover