How to check that your files are not being uploaded
Every one of these sites says it is private. How do I actually verify that?
Start from the right assumption
A privacy claim on a marketing page is not evidence. Neither is a padlock icon, a badge, or a sentence in a privacy policy — those describe intent, and the thing you want to know is behaviour. Fortunately behaviour is observable: every browser ships tools that show you exactly what a page sends, and you do not need to be a developer to read them.
Run these checks on this site. Run them on the site you were using before. The point is not to trust a different claim; it is to stop needing to trust one.
Check one: watch the network panel
- Open the developer tools. On most desktop browsers that is F12, or Ctrl+Shift+I, or Cmd+Option+I.
- Select the Network tab and make sure recording is on.
- Reload the page, then clear the list so you start from an empty log.
- Choose your file and run the operation.
- Sort by size, or look at the Method column for POST and PUT requests.
What you are looking for is any request whose payload is on the order of your file's size, and any request at all to a host that is not the site you are on. A local tool will show requests for its own code — scripts, stylesheets, WebAssembly modules, perhaps a model file — and then nothing while the work runs. An uploader will show a request carrying several megabytes at the moment you press the button.
Check two: take the network away
This is the strongest check, and it needs no expertise at all. Load the page normally, use the tool once so any engine it needs is cached, then disconnect: turn on airplane mode, switch off Wi-Fi, or use the offline toggle in the developer tools. Now process a file.
If it completes, the processing cannot have happened anywhere but on your machine. There is no ambiguity to argue about. If it fails or hangs, something in the pipeline needed a server — which may be legitimate, such as a model file that was not cached yet, but you now know to ask which.
Check three: read the content security policy
A content security policy is a header the site sends and the browser enforces. Its connect-src directive lists the destinations the page is permitted to open a connection to. If connect-src is limited to the site's own origin, the browser itself will block an attempt to send anything elsewhere, regardless of what the page's code tries to do.
To read it, open the Network tab, click the document request — usually the first row — and look at the response headers for Content-Security-Policy. A policy containing connect-src 'self' with no external hosts is a meaningful, browser-enforced constraint, not a promise.
What each check proves
| Check | What it proves | What it does not cover |
|---|---|---|
| Network panel | What this page sent during this session | A different code path, a later version of the site, or a request made after you stopped watching |
| Offline test | The processing itself runs locally | Whether something is queued and sent once you reconnect |
| Content security policy | Where the browser will permit connections at all | Anything permitted by the policy, including the site's own origin |
| Reading the source | What the shipped code contains | Effort; and it must be repeated when the site changes |
Together they are strong. Individually each has a gap, and anyone telling you a single check settles the question is oversimplifying.
Signals that a tool is not local
- A progress bar that moves at a speed unrelated to your device — smooth and identical on a fast laptop and an old phone.
- A result delivered as a link to a download URL on their domain, rather than as a file your browser already holds.
- A message about files being deleted from their servers after a number of hours. That sentence is an admission that the files were there.
- A queue or a rate limit. Your own processor does not have a queue shared with other people.
- The tool works with the network disconnected only for the first small file, then stops.
The limits of verification
Verification tells you about the version of the site you tested, on the day you tested it. A site can change tomorrow. That is why the checks that matter most are the structural ones: a restrictive content security policy and a working offline test are properties of how the application is built, not promises about a particular release.
Two things stay outside every check on this list. A browser extension can read the contents of any page, including the file you loaded into it, and no site can prevent that. Your operating system can see every file you open. If a document is sensitive enough that those matter, process it in offline software on a machine you control, and treat any website — this one included — as the wrong tool for that job.
Tools for this
Sources
- W3C — Content Security Policy Level 3
- MDN — Content-Security-Policy connect-src
- Chrome DevTools — inspect network activity
- MDN — Firefox Network Monitor