Hundreds of sites say your files never leave your browser. The sentence costs nothing to write and there is no badge, certificate or audit behind it. If it is untrue, the document you were being careful with has been uploaded to a stranger's server — which is the one outcome you were trying to avoid by looking for that sentence in the first place.

You do not have to take anyone's word for it. Three tests settle it, and they get harder to fake as you go down the list. The first needs nothing but the device you are holding.

Test one: turn the network off

Load the page and let it finish. Then switch the device to aeroplane mode, or turn the wi-fi off properly. Now add your file and use the tool.

If the result appears, the work happened on your machine. There was nowhere else for it to happen. A site that processes on a server stops dead at this step, because the upload it depends on has nothing to travel over.

Two honest caveats. A site could in principle queue an upload while you are offline and send it when you reconnect — a service worker can hold a request for later — so reconnect and watch the network for a moment before you call it settled. And the reverse is not proof either: a page that fails offline is not necessarily uploading. It might be fetching a font or a language pack it did not ship with. That is a download coming to you, which is a different thing from your file going out, and the next test tells the two apart.

Test two: read the network panel

The first test shows the page does not need the network. This one shows whether it uses it. Every desktop browser has the panel built in.

  • Open the tool page, then press F12 on Windows or Cmd + Option + I on a Mac. In Safari, switch on the Develop menu in Settings under Advanced first.
  • Click the Network tab and leave it open.
  • Press the clear button so the list is empty. This is the step people skip, and it is the one that matters: it separates loading the page from using it.
  • Add your file and run the tool. Watch what appears.

On a page that works locally, nothing appears. Not a small request, not an encrypted one — no new rows at all.

If rows do appear, the size column tells you what they are. An upload has to carry the bytes of your file, so a 10 MB document cannot leave your machine without roughly 10 MB showing up there. A few hundred bytes going out is a counter or an error report, which is worth knowing about but is not your document. Click any row and look at the request payload if you want to be certain.

An upload cannot be small. The bytes have to appear somewhere in that list.

What you will legitimately see before you clear the list is the page itself: the HTML, the stylesheets, the JavaScript that becomes the tool, the fonts. Fifteen to twenty rows is normal. Requests to a third-party domain in that group are not evidence of an upload — they are usually fonts, ads or analytics — but they are worth noticing, because they are companies watching you use the page even if they never see the file.

Test three: read one header, run nothing

The first two tests ask you to run an experiment and trust that the result generalises. The third does not. A site can instruct your browser to refuse, in advance, any attempt by that page to send data anywhere. The instruction is a header, your browser enforces it, and you can read it without loading the page at all:

curl -I https://example.com/the-tool-page

Look in the content-security-policy line for connect-src. That directive governs the ways a page can send data out: fetch, XMLHttpRequest, WebSocket, EventSource and the beacon that analytics uses. Whatever origins it lists are the only places the page is allowed to talk to. Anything else, the browser blocks — not by asking the page nicely, but by refusing the connection.

connect-src 'none' means no origin at all. That is the version worth looking for, because it includes the site's own server, and the site's own server is exactly where an upload would go. connect-src 'self' sounds strict and proves nothing here: same-origin is where the file would be sent.

This is why the header is a stronger claim than any promise on the page. A site that processes files on a server cannot ship it. The moment they do, their own tool stops working at the first click, because the upload it depends on is the first thing the browser refuses. It is not a rule they have chosen not to adopt — it is one their architecture cannot survive.

Four ways this check can mislead you

  • Read the header name to the end. content-security-policy-report-only enforces nothing. It logs violations and lets them through, and at a glance it reads exactly like the real thing.
  • Policies can differ per page. Check the header on the page you are actually going to use, not the home page. A site can be strict where it is cheap and loose where the tool lives.
  • connect-src is not the only way out. It does not govern navigation, form submission, or loading an image — so a determined page could still put a few hundred characters into an image URL. It cannot get a 10 MB file out that way, and the attempt would show in the network panel, but 'none' is not a vow of silence.
  • A header is true when you read it. It can change with the next deployment, so a check is a snapshot rather than a guarantee. Check again when it matters.

If curl returns nothing useful, some servers answer a HEAD request differently from a normal one. Fetch the page and print only the headers instead: curl -s -D - -o /dev/null https://example.com/the-tool-page. A policy can also be set inside the HTML with a meta tag, so it is worth searching the page source for content-security-policy before concluding there is none.

What this looks like on a site that passes

Ours is one example, and the numbers are dated so you can hold us to them. On 6 September 2026 we drove a real browser at our Compress PDF page with a 0.66 MB file and logged everything: loading the page made 16 requests, every one of them to ekaanhub.com; adding the file made none; processing it made none; and no request in the whole session carried a body larger than 2 KB.

Run curl on that page and connect-src 'none' is in the header. Five of our tool pages do not carry it, and we would rather name them than have you find them: PDF to Text, PDF to Word and PDF to Excel download recognition data for scanned pages, and Edit PDF and Watermark PDF fetch a font when you type in Hindi or another Indian script. Those are downloads coming inward. On those five, tests one and two are how you check, which is the same position every other site is in.

Try the three tests on us and on whatever site you were about to use. That comparison is the point of the article — not that we pass, but that most sites making the same promise cannot be checked at all.