How to Tell if a Website Uploads Your Files (60-Second Check)

Open your browser's developer tools, switch to the Network tab, and use the tool on a test file. If you see a POST or PUT request carrying your file, it uploaded. If the request list stays quiet, it didn't. The simplest version needs no jargon at all: load the page, turn off your Wi-Fi, and try the tool — a genuinely client-side tool keeps working.

What "client-side" actually means

Client-side processing means the work happens inside the web page on your own computer, using your browser's built-in capabilities, and your file is never transmitted to a server. The website sends code to you; you do not send data to the website.

The distinction is physical, not contractual. A server-side tool receives a copy of your file. Once that copy exists, its fate depends on the operator's retention policy, storage configuration, and legal jurisdiction. A client-side tool never creates that copy, so there is nothing to retain, misconfigure, or hand over.

Browsers can do a surprising amount of this natively. The Canvas API resizes, crops, and re-encodes images. WebAssembly runs compiled C or Rust libraries at near-native speed for things like PDF manipulation. WebGL and WebGPU handle filters and effects. Machine-learning runtimes such as ONNX Runtime Web and TensorFlow.js run neural networks in the tab. None of that requires a round trip.

The DevTools Network-tab walkthrough

This works in Chrome, Edge, Firefox, and Safari (Safari requires enabling the Develop menu in Settings → Advanced first).

1. Load the tool's page, then open developer tools. Press F12 on Windows or Linux, or Cmd+Option+I on macOS. Select the Network tab.
2. Clear the request log. There is a circle-with-a-slash icon at the top of the panel. Clicking it empties the list, so anything that appears next was caused by you, not by the page loading.
3. Use the tool on a test file. Pick something disposable — a screenshot, a stock photo. Run the whole workflow: select the file, apply the operation, download the result.
4. Read the Method column. GET requests fetch things to you. POST and PUT send things from you. Your file can only leave in a POST or a PUT.
5. Inspect anything suspicious. Click a POST request and open its Payload or Request tab. If your file was uploaded, you will typically see a multipart form body with your actual filename in it, and a request size in the same ballpark as the file itself.

A truly client-side tool produces a distinctive pattern: a burst of activity while the page loads its HTML, CSS, JavaScript, and fonts — then silence. You drag in a 12 MB photo, the tool processes it, you download the output, and the network panel records nothing at all.

The Wi-Fi-off test

If reading request methods is not your idea of a good time, there is a version anyone can run.

Load the page and wait for it to finish. Then disconnect from Wi-Fi or unplug the ethernet cable. Now use the tool.

If it converts your file and hands you a download, the processing was happening on your machine — it could not have been anywhere else. If it spins forever or throws a network error, your file was being sent somewhere. This test cannot be gamed by marketing copy, and it does not require you to trust a privacy policy, a certification badge, or a blog post.

One caveat: give the page a moment to finish loading before you disconnect, and be aware that some tools fetch a library or model on first use rather than at page load. If a tool fails offline, reconnect, run it once, then disconnect and run it a second time before concluding anything.

A model download is not an upload

That caveat deserves its own section, because it is the single most common false positive.

AI-powered browser tools — background removers, upscalers, object detectors — need a trained model to work. That model is a file, often tens or hundreds of megabytes, and it has to reach your browser somehow. So the first time you use one of these tools, you will see a large network transfer. That is expected and it is not an upload.

The direction is what matters:

• A model download is a GET request for a .onnx, .wasm, .bin, or .json file, usually from a CDN such as jsDelivr, unpkg, or cdnjs. Data flows to you. Your image is not involved and the request happens whether or not you have selected a file.
• An image upload is a POST or PUT whose body contains your file. Data flows from you. It only happens after you pick a file, and its size tracks the size of your file.

So the question is never "did the page use the network?" It is "did my file go out?" Sort by method, ignore the GETs, and look at what the POSTs contain.

Claims versus proof

Every tool on the internet now advertises privacy. "No upload." "100% secure." "Files deleted immediately." Some of those claims are true, some describe a one-hour retention window in a way designed to sound like zero, and some are simply false. None of them are verifiable by reading them.

The check above is verifiable. It takes a minute, it works on any tool from any vendor, and it returns a fact rather than an assurance. Run it on the tool you have been using for years. Run it on whatever ranks first for your search. And run it on ours — we would rather you confirmed it than believed it.

Verification beats trust, and in this case verification is nearly free. A privacy claim you have tested yourself is the only kind that means anything.