How to check whether a website uploads your files
Claims about privacy are cheap. These two tests take under a minute each and give you a definitive answer about where your file actually goes.
Ahmed Kobbi · · 5 min read
Can you trust a site that says it does not upload?
Almost every file-handling website says something reassuring. 'Your privacy is important to us.' 'Files are deleted automatically.' 'Secure processing.' These phrases are compatible with uploading your file, storing it, logging it and retaining metadata indefinitely. Even precise-sounding claims are unverifiable from outside. 'Processed in memory, never written to disk' may be entirely true and you have no way to confirm it. A privacy policy describes intent at a point in time; it is not a technical control. The good news is that one specific question — does my file leave this device — is directly observable. You do not need to trust anyone's description, because you can watch the behaviour yourself with tools already built into your browser.
Test one: the network inspector
Every major browser ships with developer tools that show exactly what the page sends and receives. Open the tool's page. Press F12, or Cmd+Option+I on a Mac, or right-click and choose Inspect. Select the Network tab. Clear the existing list using the circle-with-a-slash icon so you are looking only at what happens next. Now use the tool: add your file and run the operation. Watch the list. If your file is uploaded, you will see a request — usually a POST — whose size roughly matches your file. A 4 MB PDF produces a request of about 4 MB. Click it and the Payload or Request tab will show the file data being sent. If the file stays local, you will see nothing of that size. You may see small requests for fonts, icons, analytics or error reporting — those are normal and are not your file. The distinguishing feature is size: a request carrying your document cannot be smaller than your document. The Size column makes this easy to scan. Sort by it if the list is long.
Test two: the offline test
This is simpler, needs no technical knowledge, and is impossible to fake. Load the tool's page completely. Then disconnect from the internet — turn off Wi-Fi, switch on aeroplane mode, or unplug the cable. Do not reload the page. Now use the tool normally. If it completes and gives you the output file, the processing happened on your device. There is no other explanation: a tool that sends your file to a server cannot work without a connection. If it fails, hangs, shows a spinner forever or displays a network error, it needs a server. Your file is being transmitted, and privacy depends on that operator's policies and practices rather than on architecture. One caveat: reload the page while offline and it will fail regardless, because the page itself needs to be fetched. Load first, then disconnect, then use.
Reading the results correctly
A few nuances are worth knowing so you interpret the tests fairly. Small outbound requests during use are usually analytics or error reporting, not your file. They matter for tracking questions but they are not file uploads. Judge by size. Some tools are hybrid: most operations run locally while one specific feature calls a server. A thumbnail downloader must fetch the image from the video platform, for example — that is inherent to the task rather than a privacy failure. Test the specific operation you care about. A tool failing offline is not proof of bad faith. Some genuinely need server capability, particularly for OCR or machine-learning features that would require downloading a very large model. The test tells you where processing happens, not whether the operator is trustworthy. And a tool passing both tests is telling you something quite strong: not that its policies are good, but that its policies are largely irrelevant to your file, because the file never reached them.
What to do with the answer
Match the tool to the document rather than applying one rule to everything. For anything containing a signature, an identity document, financial figures, medical information or unpublished commercial material, use a tool that passes both tests. The privacy property here is structural rather than promised, which is the only kind that survives a company being acquired, changing its terms or being compelled to produce data. For a public brochure, a stock photo or a document you would happily email to a stranger, convenience is a perfectly reasonable basis for choosing. It is also worth running these tests occasionally on tools you already use. Sites get rebuilt, acquired and re-architected, and a tool that processed locally two years ago may not today. The test takes a minute. Every file-handling tool on this site passes both. That is not a claim asking to be believed — it is an invitation to check, which is rather the point.
Frequently asked questions
How do I open the network inspector?
- Press F12, or Cmd+Option+I on a Mac, or right-click the page and choose Inspect. Then select the Network tab and clear the list before using the tool.
What does an upload look like in the Network tab?
- A request — usually a POST — with a size roughly matching your file. A 4 MB document produces a request of about 4 MB. Sort by the Size column to spot it quickly.
What if I see small requests while using the tool?
- Those are typically analytics, fonts or error reporting, not your file. A request carrying your document cannot be smaller than the document itself.
Why must I load the page before going offline?
- The page's own code has to be downloaded first. Reloading while offline fails regardless of how the tool processes files, which would give you a false negative.
Does failing the offline test mean a tool is untrustworthy?
- No. It means processing happens on a server. Some tasks genuinely require that. It tells you where your data goes, not whether the operator behaves well.
Should I retest tools I already use?
- Occasionally, yes. Sites get rebuilt and acquired, and a tool that ran locally in the past may not now. The test takes about a minute.
Last updated:
Written by Ahmed Kobbi, who builds and maintains SwiftTooly.