How to Check Whether an Online File Tool Is Actually Uploading Your Files

Every online file tool tells you it respects your privacy. That claim costs nothing to make and nothing to fake, so it carries almost no information. The useful thing is that you don’t have to evaluate the claim at all. Whether your file left your computer is a question about network traffic, and your browser already records all of its network traffic and will show it to you.

There are two checks. The first watches what the page does at the moment you hand it a file. The second removes the network entirely and sees whether the tool still works. Together they take about a minute and they answer the question directly, for any site, including this one.

Why the marketing copy cannot settle it

The words that appear on file-tool landing pages are mostly compatible with uploading. “Secure” usually means the connection is HTTPS, which describes how your file travels to the server, not whether it travels. “Encrypted” may mean the same thing, or that files are encrypted at rest on a disk you don’t control. “We delete your files after an hour” is a statement about retention, which only makes sense if the files arrived in the first place.

Even “private” and “we never look at your files” are promises about behaviour rather than descriptions of architecture. They may be entirely sincere. They are just not verifiable from the outside, and a sincere promise and an insincere one look identical in body copy.

The phrase that would be meaningful is a technical one: that processing happens in your browser and the file is never sent. That claim is falsifiable, which is what makes it worth something. You can check it in a minute, and this article is about how.

What you are actually looking for

A file cannot be processed on a server unless its bytes get to that server. That means a network request leaving your machine carrying the file’s content in its body. Nothing else counts, and nothing else needs to be interpreted.

This is a useful thing to hold onto, because a page in front of you will make plenty of other requests: for its own JavaScript and CSS, for fonts, for analytics pings, for ads, for icons. Those are downloads and small signals. The thing you are hunting for has a particular signature: it appears right after you select your file, it goes out rather than coming in, and it is roughly the size of your file.

That last property is the one that does most of the work. Marketing copy is ambiguous; a request body of four megabytes appearing the instant you pick a four-megabyte photo is not.

Method 1: watch the network while you use the tool

Open the tool’s page first, and let it finish loading before you do anything else. You want the page’s own startup traffic out of the way so it doesn’t clutter what comes next.

1. Open your browser’s developer tools. F12 works in most desktop browsers, as does right-clicking the page and choosing the inspect option. On a Mac, Cmd+Option+I is the usual shortcut.
2. Select the Network panel.
3. Apply the Fetch/XHR filter. In Chrome this is one of a row of type filters across the top of the panel; Firefox has an equivalent filter. This hides images, scripts and stylesheets and leaves the category that file uploads almost always fall into.
4. Clear the log, so the list starts empty. Chrome DevTools labels this control Clear.
5. Now select your file, or drag it onto the drop zone, and let the tool do its work. Watch the list while it runs.

A caution worth taking seriously: use a file you would not mind a stranger having. The point of the test is to find out whether the file gets sent, and if the answer turns out to be yes, it has already been sent by the time you know. A holiday photo or a throwaway PDF is the right material for this.

It is also worth removing the Fetch/XHR filter once and repeating with All selected. It is noisier, but an upload sent by some less common mechanism will still be visible there, and seeing the full picture once teaches you what a page’s normal chatter looks like.

Reading what you see

An upload looks like this. A new entry appears within a second or two of you selecting the file. Click it, and its headers show a method of POST or PUT rather than GET. It has a request body, and the body is either multipart form data or a raw binary blob. Its size is on the order of your file’s size, allowing for compression and encoding overhead. In Firefox’s network monitor the sent request data appears under a tab named Request; Chrome shows it in an equivalently named pane in the request’s detail view. Note that Chrome’s default columns do not include the request method, so you generally have to open a request to see it rather than reading it off the list.

Client-side processing looks like almost nothing. You pick the file, the tool works, a result appears, and the request list is still empty, or has gained only small entries unrelated to the file — an analytics beacon, an ad call. The file never generated a request because it never needed to leave the page.

There is a middle case you should know about so it doesn’t mislead you. Some tools that genuinely run locally will still fetch something when you first use them: a WebAssembly module, a compression library, a machine-learning model. These arrive as GET requests for a fixed URL, they carry no request body, and their size has no relationship to your file — the same download happens whether you gave the tool a 200 KB image or a 200 MB one. That asymmetry is the tell. Code coming in is not your file going out.

Method 2: pull the plug

The second check needs no interpretation at all, which is why it is the better of the two.

1. Load the tool’s page and wait for it to finish loading completely.
2. Disconnect from the network. Turn off Wi-Fi, or select Offline from the throttling dropdown in the Network panel, which makes the browser refuse network access to the page.
3. Now use the tool. Select your file and run it.

If it produces a correct result with no network available, no server was involved. This is not a matter of reading the evidence carefully; there was no route to a server for the file to take.

If it hangs, errors, or shows a spinner that never resolves, that is suggestive but not conclusive. A tool that runs locally can still fail offline for an innocent reason: it may not yet have downloaded a library or model it needs, because it only fetches those on first use. Reconnect, run the tool once so anything it needs gets cached, then go offline and try a second time. If it works on that second attempt, the failure was about loading code, not about sending your file.

Running both checks here

This site processes files in the browser. I can tell you what is in the source: the tools take your file from a standard file input or a drag-and-drop handler, hand it to a library running on the page, and produce a result you download from browser memory. None of the tool pages contain an upload endpoint; the site is served as static files with no server-side processing behind it. (There is a separate, opt-in developer API at api.filewash.app, described on the for-agents page, which does send files to a server — nothing on this website uses it.) The relevant browser capability is the File API, whose FileReader interface MDN describes as enabling web applications “to asynchronously read the contents of files (or raw data buffers) stored on the user’s computer” (retrieved 31 July 2026).

But you have no reason to take that on faith, and the whole argument of this page is that you shouldn’t have to. Open the image compressor or the metadata stripper, run either check, and see what happens on your own machine.

Some honesty about what you will find alongside it. This site is not silent on the network. It loads a cookieless analytics beacon on every page, and if you accept the consent banner it loads Google Analytics as well, so the request list will not be completely empty. Several of the PDF tools fetch a PDF rendering worker script from a public CDN the first time you use them, and the background remover downloads a sizeable machine-learning model. Those are the middle case described above: fixed downloads of code and model data, unrelated in size to your file. Because of them, some pages will fail the offline test on a cold first run and pass it on the second, after the code is cached. That is a real limitation of the offline test on this site and I would rather you hear it here than discover it and conclude the check is broken.

What these checks do not prove

Be clear-eyed about the scope. Both methods observe one page, in one browser, during one short window.

• They cover the moment of processing only. A page could hold your file and send it later, on a timer or when you navigate away. If you want to rule that out, leave the Network panel open and keep watching for a while after the result appears.
• They apply to the page you tested. A site can process locally on one tool and on a server for another, and that is often a legitimate engineering decision rather than a deception. Check the tool you actually intend to use.
• Your extensions make requests too. Some of the traffic you see may belong to a password manager or a content blocker rather than the site. Testing in a private window with extensions disabled gives you a cleaner reading.
• A result is a snapshot, not a guarantee. Sites get rewritten. What you verified in March says nothing about what the same URL does in November.
• Local processing is not the same as safe. A tool that keeps your file on your machine can still produce a broken output or quietly discard data you needed. That is a separate question from where the bytes went.

What the checks do give you is the thing marketing copy cannot: a direct observation, made by you, about the specific file you care about.

The one-minute checklist

1. Open the tool’s page and let it finish loading.
2. Open developer tools with F12, and select the Network panel.
3. Filter to Fetch/XHR and clear the log.
4. Select a file you don’t mind losing control of, and run the tool.
5. Look for a new entry with a POST or PUT method, a request body, and a size close to your file’s. That is an upload. No such entry means the file stayed local.
6. Reload the page and let it settle. Run the tool once so any libraries it needs are cached.
7. Set the throttling dropdown to Offline, or switch off Wi-Fi.
8. Run the tool again. If it still produces a correct result, nothing was uploaded.

Worth doing once on any tool you are about to feed something sensitive. After you have done it a few times you will stop reading privacy claims on landing pages altogether, which is the right outcome.

For the related question of what tools state in their own published policies, see what popular online file tools say they do with your uploads, and for why some jobs genuinely need a server, client-side versus server-side file processing.

FileWash is built and maintained by Cassi Lup. Details of the DevTools controls named above come from the Chrome DevTools Network panel reference and the Firefox Network Monitor documentation. Labels move around between browser versions, so if something is not where this describes, look for the nearest equivalent rather than assuming the check has failed.