The short answer: open the page in a fresh tab, open the developer tools, clear the network list, then drop your image. If nothing new appears in that list, nothing was uploaded — not because the site says so, but because an upload is a network request and the browser records every one of them before the page gets a chance to comment. The test takes about five minutes and it does not require you to trust the green screen background remover you are testing.
This matters because the claim is now universal. Every tool in this category says some version of "your files never leave your device", and almost none of them give you a way to check. A claim you cannot test is marketing copy, however true it happens to be. The useful thing about this particular claim is that it is falsifiable: if bytes left your machine, there is a record, and the record is kept by your browser rather than by the site.
Below is the exact sequence, the pass condition for each step, what a real upload looks like next to local processing, and — because a page that only tells you what you want to hear is not worth much — the three things that stay true even when the network list comes back empty.
Are my files uploaded anywhere?
That question is really two questions, and they are answered by different evidence. The first is whether the page can send your file: does it contain code with the ability to make an outbound request? The second is whether it did, during your session, with your file. A source check answers the first. The network log answers the second. You want both, because either one alone leaves a gap.
For this page, the answers are no and no. The tool reads the file into memory, copies the pixels into a canvas, runs a per-pixel comparison against the key colour, and encodes the result with the browser's own encoder. Nothing in that sequence needs a socket. Two scripts ship with the page and neither one contains a call to fetch, XMLHttpRequest, sendBeacon or WebSocket — you can confirm that with the source check further down, in about twenty seconds, without taking my word for it.
But "this page does not send" is a statement about one page. The skill worth keeping is the test, because the same five minutes will tell you what any other tool in this category actually does — including the ones that make the identical claim and mean something different by it.
Three ways bytes leave a tab, and where each one shows up
There is no fourth way. A browser tab can send data through a document navigation, through a scripted request, or through a persistent connection, and all three land in the same panel. The point of learning the signatures is that you stop reading request names and start reading request bodies, which is the only part that can carry an image.
| Method | What it looks like in the list | Where the bytes hide |
|---|---|---|
| Form post | Type document, method POST, one entry that appears the moment the file is chosen | Headers → Request Payload: Content-Disposition: form-data; name="file"; filename="…" |
| Scripted request | Type fetch or xhr, usually POST or PUT, often to a path containing "upload" or "api" | Request Payload as a blob, as base64 text, or as multipart form data |
| Beacon | Type ping, fires late, survives the page closing | Small body by design — this is the channel for telemetry, not for a 12 MB image |
| Persistent connection | Type websocket, one entry that stays open for the whole session | The Messages tab of that entry — frames are listed there with their length in bytes |
Two things that look like uploads and are not, so you do not chase them. A data: URL is a string that carries the file inline in memory — it never becomes a request, and finding one in the page source or in a variable proves nothing either way. And a request served by a service worker still appears in the list, labelled as coming from the worker; interception hides the server, not the request. If neither of those explains an entry, the entry is real traffic and you should read its body.
The five-minute test, in the order that rules things out fastest
Do this in a new tab, not the one you have been using all morning. Old tabs carry cached responses, a service worker from an earlier visit, and whatever your extensions have already injected — all of which make the list harder to read. Open the developer tools first, then load the page, so you capture the initial requests as well.
Step 1 — set the panel up. Network tab. Tick Preserve log, so a navigation does not wipe what you are looking at. Leave the throttling menu on its default; you will change it once, on purpose, in step 6. Do not filter anything yet — you want to see the whole list before you decide what matters.
Step 2 — load the page and count the baseline. Reload once and let it settle. Write down the number of entries and the domains involved. On a page like this one the baseline is short and entirely same-origin: the document itself, a stylesheet, a script, and usually a favicon request. If your baseline already contains third-party domains, note them now, because later you will need to tell "a new request" apart from "a request that was always there".
Step 3 — clear the list. This is the step almost everyone skips, and skipping it is why the test gets misread. Press the clear button so the panel is empty, with the page still loaded and working. From here on, anything that appears is caused by what you do next, not by the page load.
Step 4 — drop the file and wait ten seconds. Choose an image that is big enough to be worth stealing: a few megabytes, not a 40 KB icon. Watch the list, then keep watching. Uploads are frequently deferred by a debounce, a queue, or a worker, so a list that is empty at one second and non-empty at eight is a failed test, not a pass. Pass condition: zero new entries. Fail condition: any new entry whose body is roughly the size of your file.
Step 5 — if something did appear, read its body, not its name. A request called collect that carries 200 bytes is analytics. A request called analytics that carries 6 MB is your image, whatever it is named. Open Headers and look at Request Payload. Then open Timing and look at the Request sent segment: for a large body over a normal connection this segment is measured in hundreds of milliseconds or more, while a small one is single-digit. The Size column in the list measures what came back, so it tells you nothing about what went out — that is the single most common misreading of this panel.
Step 6 — run it offline. With the page loaded and the image still on screen, set the throttling menu to Offline, then drop a second image. If the new image keys normally, the computation happened on your machine, because a machine that cannot reach the network cannot have its pixels processed by it. If the tool stalls, spins, or throws a network error, you have found the answer, and it is the other one.
Step 7 — export the log and search it. Right-click anywhere in the request list and save everything as a HAR file with content included. Open that file in a text editor and search for four strings: your file's name, multipart/form-data, filename=, and base64,. Pass condition: your filename appears zero times. This step exists because the panel shows you what happened while you were watching, and the log shows you what happened after you looked away.
What a real upload looks like next to local processing
Six signals, and any one of them is enough. The reason to know all six is that a well-built upload can hide any single one: it can be fast, it can be small in the panel, it can look like a normal request. It cannot hide all six at once.
| Signal | If it uploads | If it processes locally |
|---|---|---|
| Entries added after the drop | At least one, and it belongs to the file, not to the UI | None |
| Request body size | Tracks the file: an 8 MB image produces a body near 8 MB, or a third larger if base64 | No body exists to measure |
| Time to first result | Rises with your upload speed and falls with your download speed; changes when you tether to a phone | Rises with image area and falls with a faster CPU; unchanged by the network |
| Offline behaviour | Fails, spins, or waits — the result depends on a machine you cannot reach | Identical to online, because the network was never part of the calculation |
| A very large file | Handled gracefully until the server rejects it, usually with a 413 Payload Too Large | The tab slows or crashes — the limit is your memory, and the failure is local |
| The HAR file | Your filename is in it, in a body or a header | Your filename appears nowhere in it |
The timing row is the one that survives clever engineering. A local tool gets faster when you close other tabs and slower when you process a bigger image, and it does not care whether you are on hotel Wi-Fi. An upload-based tool does the opposite on both counts, and the difference shows up as a stopwatch reading you can take without opening any panel at all.
Why the offline run is the one you cannot misread
Every other step asks you to interpret something: is this request mine, is this body large, is this entry old. The offline run asks you to interpret nothing. Either a new image gets keyed while the network is unavailable, or it does not.
The trap is testing it on the wrong thing. A page that loads while offline proves only that the page was cached — service workers exist precisely to do that, and a cached page is not evidence about your pixels. What you are testing is a new file, chosen after the connection is gone, producing a new result. That result cannot have come from a server you cannot reach, and there is no caching mechanism that can invent an alpha channel for an image the server has never seen.
For the strongest version, use airplane mode or disable the network adapter rather than the throttling menu. The menu is a browser-level simulation and a determined page could, in principle, behave differently under it; pulling the connection is not simulated by anything. On a laptop, unplug the cable and turn off Wi-Fi, then drop a third image. If it keys, the case is closed.
Are my uploaded videos secure and private?
Read that question again and notice what it assumes: that an upload happened. Half the time it did not, and the word "uploaded" is doing work that nobody verified. So the order is fixed — first establish whether bytes left, then talk about what happens to them. The test above is the same test for video; only the numbers change, and they change in your favour, because video is large enough that an upload cannot hide. A 40 MB clip that gets sent produces a 40 MB request body. There is no version of that which looks like a normal page load.
A browser tool that handles video locally has to decode frames on your machine, either through the video element and a canvas or through the newer frame-level decoding interfaces. Either way the decode is local, the keying is local, and the export is a blob assembled in memory. A tool that shows a spinner and a percentage while sending nothing over the network is not doing that — it is either very slow at local work or it is not doing local work. Watch the list and you will know which within one clip.
This page is the still-image case: PNG, JPG, WebP and BMP in, transparent PNG out. It does not accept video, and pretending otherwise would be the kind of claim this whole article is asking you to distrust. If your source is a clip, the video workflow covers the settings and the export, and the network test still tells you what kind of tool you are pointing at it.
And if the answer turns out to be that it does upload, "secure and private" becomes a question you cannot answer from the outside. Retention period, encryption at rest, who can access the bucket, whether deletion is real or a flag — none of that is visible in a network panel, and all of it lives in a policy you have to take on faith. That asymmetry is the actual argument for local processing. It does not make a tool more trustworthy; it removes one promise you would otherwise have to believe.
Three things that are still true when nothing is uploaded
A page that only lists the ways it is safe is not giving you a test, it is giving you a brochure. These three survive a perfect score on every step above, and knowing them is what stops "no upload" from quietly turning into "anonymous".
1. The page itself was requested from a server. Whoever serves it saw your IP address, your browser's user-agent string, the time, and the URL. That is true of every website, including this one, and it is unrelated to your image — but it means "your file did not leave" and "you were not seen" are different statements, and only the first one is being made here.
2. A request list with entries in it is not a failure. Analytics, ad scripts, web fonts and affiliate pixels all report page events to someone else. The honest question is not "were there zero requests" but "was there any request carrying image bytes". A tool can have a dozen third-party entries and still never touch your pixels; a tool can have one entry and send everything. Read the bodies, not the count. On this page the entries are same-origin, and the one outbound link that leaves the site does so only when you click it — at which point the destination learns where you came from, which is how links have always worked.
3. The tab is not the whole machine. A browser extension with page access can read a canvas, and no amount of local processing defends against that. Operating-system backup, sync clients and telemetry run below the browser and outside this conversation entirely. Local processing protects your file from a server you do not control. It does not protect your file from your own computer, and any tool claiming otherwise is overselling a real benefit into a false one.
What "processed locally" actually means, step by step
The phrase is vague enough to be meaningless, so here is the sequence it stands for. Once you have seen it, the network results stop being surprising — you can predict them from the architecture instead of testing for them.
- The file is read into memory. The browser decodes your image into a bitmap held by the tab. No socket is involved at any point in this step.
- The pixels are copied into a canvas and read back as an array. Every pixel becomes four numbers — red, green, blue, alpha. This is where the memory cost becomes real: a 4000×3000 image is twelve million pixels, so one copy of that array is about 48 MB, and a working tool needs at least two.
- The key is arithmetic, per pixel. Measure the colour distance from your chosen key colour, compare it against a threshold, write an alpha value, and pull the green out of the surviving pixels. A loop over twelve million pixels, no I/O.
- The result is written back and encoded. The browser's own PNG encoder turns the canvas into a blob — the same encoder that would run if you saved from any canvas, with no server in the path.
- The download is a pointer, not a transfer. The save dialog is handed a
blob:URL, which is an address inside the tab's memory. That is why the download still works with the network off, and why the exported file never has to exist anywhere else first.
This also explains the limits that otherwise look arbitrary. The practical ceiling of about 25 MB per file on a browser-based green screen background remover is not a policy decision, it is the point at which the tab runs out of room for its copies — and why a 60 MB panorama does not fail with an error message so much as take the tab down with it. A server-based tool has no such ceiling, because it is spending someone else's memory. That is the trade, stated plainly: local processing buys you the guarantee and pays for it in file size.
A twenty-second source check, and its limit
Before you drop a file anywhere, you can look at what the page is made of. View the page source, find the script tags, open each file, and search for four strings: fetch(, XMLHttpRequest, sendBeacon, WebSocket. Minified code still contains those substrings, so minification is not a hiding place. Two scripts ship with this page and the search returns nothing in either of them.
The limit of this check is worth stating: a determined developer can build those strings at runtime, load a network library from a data URL, or route the request through a worker. Source reading is corroboration, not proof. The network log is the proof, because it observes the traffic rather than the intent — which is why the five-minute test comes first in this article and the source check comes last.
Used together they cover each other's blind spots. The source check tells you whether the capability exists at all; the network log tells you whether it was used; the offline run tells you whether the result depends on it. Three cheap observations, and the claim stops being a claim. If you want to run them against this tool, the green screen background remover is the page to open — and the privacy page is where the same statement is written down, so you can compare the two.
Quick answers
Are my files uploaded anywhere?
Not by this tool, and you do not have to accept that on trust. Open the network panel in a fresh tab, clear the list after the page loads, then drop a multi-megabyte image and watch for ten seconds. Zero new entries means zero bytes left. Then set the connection to offline and key a second image: if it works, the computation was local, because a server you cannot reach cannot be doing it. Save the log as a HAR file and search it for your filename if you want the version that survives looking away.
Are my uploaded videos secure and private?
First check the premise — many browser tools never upload the video at all, and the network panel will show that in one clip, because a 40 MB file cannot be sent invisibly. If a tool does upload, then security depends on retention, encryption, access control and whether deletion is real, none of which you can verify from outside; you are trusting a policy. Local processing is worth preferring not because the company is nicer but because it deletes that promise from the list of things you have to believe.
Is this tool mobile-friendly?
Yes — the interface adapts, and on a phone you can pick from the gallery or shoot directly. But the verification above assumes a desktop browser with developer tools, and mobile browsers do not have them. The workaround is the offline test, which needs no tools at all: load the page, put the phone in airplane mode, then choose an image from the gallery and key it. If the result appears, nothing was uploaded. It is the one step of the protocol that survives losing the panel.
Is this green screen background remover free?
Yes, with no account and no per-day limit. The costs that would normally justify a subscription — server time, storage, bandwidth — do not exist here, because the work happens on your machine. That is also the honest explanation for the size ceiling: the limit is your tab's memory, not a paywall, and no payment removes it. Affiliate links elsewhere on the site are disclosed and are not part of the tool.
Can I key a blue screen, or another colour?
Yes. Pick the colour with the picker or the eyedropper and the same per-pixel comparison runs against it — nothing in the local-processing argument depends on which hue you remove. Every test in this article applies unchanged: the network does not know or care what colour you keyed. For non-green backdrops there is a dedicated page, and for the choice between the two colours, blue versus green covers the trade-offs.
Related reading: the browser-based remover, any-colour chroma key, video export and transparency, twelve checks before you export, and the channel-based still workflow.