How to Check That an Online Tool Really Doesn't Upload Your Files

Why "runs in your browser" needs checking

Almost every online file tool says it respects your privacy. Converters, PDF editors, spreadsheet viewers and image compressors all promise that your data is safe, but a promise is not evidence. I build the tools on HowToToolkit, so I have an obvious interest in asking you to trust us, and you shouldn't have to. Browsers let you verify the claim yourself in a few minutes, and the same tests work on any website, ours included.

What local processing actually means

When a page processes a file locally, JavaScript receives the file through the browser's File API, which is what a file input or a drag-and-drop gives the page. The code reads the bytes into memory, parses them, and renders the result. No network request has to carry the content anywhere. Cloud processing is the opposite: the browser sends the file to a server, usually as a multipart form upload, and downloads the result.

There is also a hybrid pattern that is easy to miss. A tool can parse the file locally but send pieces of it to a remote service for the hard part, such as OCR or an AI model. The tests below let you tell all three apart.

Test 1: watch the Network panel

1. Open the tool page, then open DevTools with F12 (or Ctrl+Shift+I, or Cmd+Option+I on macOS) and select the Network tab.
2. Tick "Preserve log" and clear the list, so that requests made while the page loaded do not clutter the picture.
3. Load a file into the tool and run the operation you care about.
4. Read the new requests. Look for any POST or PUT request, and compare the "Sent" size of each request with the size of your file.

Small requests are normal. An analytics ping, a font, or a script chunk fetched the first time you open a feature will all show up. What should worry you is a request roughly the size of your file going to a host you do not recognise. A sharper variant: create a test file that contains a unique string, such as a made-up name, then use the search function of the Network panel to look for that string in request bodies. If it appears, the content was sent.

Test 2: go offline after the page has loaded

Once the page and its scripts are loaded, set the Network throttling dropdown to "Offline", or simply turn off your Wi-Fi. Now process a different file. A tool that really works locally keeps working, because everything it needs is already in memory. This is the strongest single piece of evidence you can collect: with no connection, no upload can have happened.

One caveat prevents a false alarm. Many tools load their heavy parsing libraries lazily, the first time you use a feature. If the tool fails offline on its very first run, run it once online and repeat the offline test. A failure after that point is worth investigating; a failure before it proves nothing.

Test 3: read the headers and the documentation

A Content-Security-Policy header can include a connect-src directive, which limits the hosts that page scripts are allowed to contact. If it lists only the site's own origin, silent uploads to third parties are blocked by the browser itself. You can inspect it by selecting the page document in the Network panel and reading its response headers. Many honest sites do not set a strict policy, so its absence says nothing either way, but its presence is a useful extra guarantee.

Then read the privacy policy and any data-flow description. A trustworthy one names what is processed locally, what is sent, and why. Vague wording such as "we may share data with partners" deserves a second look. On HowToToolkit that information lives in the data-flow page in the legal section, and you are welcome to check it against what the Network panel shows.

What local processing does not cover

Passing all three tests means the file content stayed on your device. It does not mean that nothing leaves the page, and it helps to know what else may be present:

• Analytics and consent scripts. They should never carry file content, but they can carry the page URL, your IP address and similar metadata. A cookie preferences control is the place to manage these.
• Features that need a server by design. Signing in, usage quotas and any lookup against an official registry involve a request. A VAT number checker, for example, has to send the number to the registry to validate it. Judge those by what is sent, not by whether anything is.
• Browser extensions. Extensions can read page content, so repeat the test in a private window with extensions disabled if the data is truly sensitive.
• Your own machine. The file sits in memory while the tab is open, and results you download land in your Downloads folder.

A five-point checklist

1. Network panel: no upload-sized POST or PUT request while processing.
2. Unique-string search: your test content does not appear in any request body.
3. Offline run: a second file is processed with the connection off.
4. Headers: connect-src, if present, lists only origins you expect.
5. Documentation: the policy states plainly what is and is not sent.

A practical habit

Run the tests with a throwaway file first, and only then with real data. If you handle customer records, financial exports or credentials, make the check part of how you evaluate any new tool, in the same way you would read a licence before adopting a library. If you want to see the principle in action, tools such as the CSV anonymizer or the AI image metadata sanitizer are good candidates: they exist to remove sensitive information, so it is reasonable to ask them to prove they do not send it elsewhere.

None of this makes a tool correct or secure in every other respect, and a single test run is a snapshot, not a certification. Sites change, and so do the scripts they load. Rerun the tests when the stakes are high.