Skip to content

How to check that a website does not upload your file

Four checks anyone can run in a desktop browser, with what each one proves and what it does not.

By Shahzad Ali · ·

The short answer

Open your browser's developer tools, watch the Network tab while you open a file, and look for a request that sends data out (a POST or PUT) or one whose size is close to your file's. If none appears, and the file still opens with the network switched off, the site read it on your own computer.

Step 1: open the Network tab

The steps work in any desktop browser:

  • Chrome and Edge: press F12, or Ctrl+Shift+I on Windows and Cmd+Option+I on a Mac, then open Network.
  • Firefox: the same keys, then Network.
  • Safari: in Settings, Advanced, turn on "Show features for web developers", then choose Develop, Show Web Inspector, and open Network.
  • Tick Preserve log in Chrome (Persist Logs in Firefox) so the list survives page changes, and press the clear button to start with an empty list.

Step 2: open a file and read the list

Choose or drop a file; a harmless test file is best. Every line in the Network tab is one request. Look at the Method, Size and Type columns, then click the Fetch/XHR filter, which shows only the requests the page's code sends on its own, the usual way files are uploaded:

  • A POST or PUT request right after you choose the file, especially one close to the file's size, is an upload. Click it and open Payload (Chrome) or Request (Firefox) to see what was sent.
  • Requests to another domain at that moment, such as an analytics, storage or API address, mean something left the page. Check what they carry.
  • GET requests for .js, .css or font files are the site loading its own code. They download to you and do not carry your file.
  • WebSocket (WS) entries can carry data too. Open them and look at the Messages tab.

Step 3: the offline test

Load the site, then disconnect: turn off Wi-Fi, or change "No throttling" to "Offline" in the Network tab. Now open a file. If it opens and you can work with it, the reading happens in your browser; a site that needs its server shows an error or keeps spinning. Reconnect afterwards and watch the Network tab for a minute, because a page could in principle keep a copy and send it later.

Step 4: read the site's security policy

Click the first request in the list (the page itself), open Headers and find content-security-policy under Response Headers. Its connect-src part lists the addresses the page's code may contact: connect-src 'self' means only the site's own address, and the browser itself blocks everything else. A policy is a strong signal but not proof on its own, so combine it with steps 2 and 3.

What these checks show on OpenAnyDoc

Try them on the CSV viewer, the Excel viewer or the JSON viewer: opening, editing and downloading a file sends no Fetch/XHR request, no POST and no request to another site. The page's policy is connect-src 'self', and once a tool page has finished loading, its files open with the network off. The privacy policy names the one thing the host, Cloudflare, does see: ordinary page requests, never file contents.

What "processed in your browser" does not cover

It keeps the file off the network, not safe on your computer. Anything with access to the device, such as a browser extension allowed to read every site, can still see the page. Use a browser profile without extensions for sensitive files, and close the tab when you are done: the file lives in the page's memory and is gone when the tab closes.

It also stops at your computer: once you send the file to someone, or paste it into an AI assistant, its contents travel with it. Before that, mask the personal data in it; the guide on how to anonymize a file before sharing it shows the steps.

Questions?

Write to support@openanydoc.com. If a check on OpenAnyDoc shows a request you did not expect, tell us what you saw.