A browser-based tool downloads its code once and then processes your file inside the tab, with no server involved. You can check that without trusting the site: load the page, switch off your network, and run the tool. If it still works, the file had nowhere to go.
01Two ways a PDF website can work
Upload, process, download
Your file is sent to the company’s server, processed there, and the result is sent back. Privacy depends on what the server keeps, for how long, and who can reach it.
Process in the tab
The page downloads a PDF engine (JavaScript and WebAssembly) and runs it on your device. The file is read from your disk into the tab’s memory and the result is saved back from there.
The second design is possible because browsers can now run demanding code: rendering pages, recompressing images, even OCR. It also has limits: a phone has less memory than a server, so very large files can be slower, and the first visit downloads the engine.
02Why a site’s own counter is not proof
Some sites, pdfnex included, show a live list of the network requests the page has made. Browsers expose this list through the Resource Timing API, which MDN describes as part of the Performance API that “enables retrieving and analyzing detailed network timing data for the loading of an application's resources”.[2] It is useful, but the page’s own script builds the display, so it is only as trustworthy as the site. Treat it as a convenience. The checks below do not depend on the site at all.
A privacy claim you can test with the network unplugged is worth more than any badge. The tests below work on every PDF site, including ours.
Our view
03Check 1: the airplane-mode test
- Open the tool page and let it finish loading.
- Turn on airplane mode, or switch off Wi-Fi and unplug the cable.
- Add your file and run the tool, then save the result.
- If the result appears and saves, the processing happened on your device. An upload-based tool fails at step 3.
This is the strongest simple test, because a page cannot send anything while the device has no network. One caveat: a page could, in principle, queue data and send it later when you reconnect, which is what the next two checks cover.
04Check 2: watch the network yourself
Every desktop browser has developer tools with a Network panel. Chrome’s documentation notes: “So long as you've got DevTools open, it will record network activity in the Network Log”.[3] Open it (F12, or Cmd+Option+I on a Mac), select the Network tab, then add your file and run the tool. Look at what appears after you add the file: every request, its destination and its size are listed. A request to another domain, or one whose size is close to your file’s, deserves a question. Keep DevTools open through reconnecting if you did the airplane-mode test first.
05Check 3: read the site’s rules
A site can tell the browser which servers its own scripts may talk to, using a Content-Security-Policy header. The connect-src directive is the one that matters for uploads: per MDN it “restricts the URLs which can be loaded using script interfaces”, including fetch(), XMLHttpRequest, WebSocket and Navigator.sendBeacon().[1] A policy of connect-src 'self' lets scripts talk only to the site’s own origin; it does not stop the site’s own server from receiving data, so read it together with checks 1 and 2.
To read the header: in the Network panel, click the first request (the page itself) and look under Response Headers for content-security-policy. pdfnex prints its full header on Verify privacy, copied from the same constant the server sends.
| Check | Proves | Does not prove |
|---|---|---|
| Airplane mode | Processing happens on your device | That nothing is sent later |
| DevTools Network | Every request the page made, with sizes | What a server does with ordinary requests |
| CSP connect-src | Which origins scripts may contact | What the site’s own origin receives |
These checks describe standard browser features. They help you assess a site; they are not a security audit.