Prove a PDF tool is local: the Wi-Fi off test, and what the network panel shows

Inspect is a good tool to test with: it reads a PDF and changes nothing, so any file will do.

Why test at all

Almost every PDF site says your files are safe. Some mean “we delete uploads after an hour”, some mean “the connection is encrypted”, and a few mean “the file never leaves your device”. The sentences sound alike and describe 3 very different things. A promise you can test is worth more than a policy you have to believe, and these tests take about a minute. They work on any site, ours included; do not take our word for it either.

Test 1: turn Wi-Fi off

This is the test anyone can do, and the one we suggest on our privacy page.

1. Open the tool while you are online. Use a file that is not confidential, such as a public form you downloaded.
2. Run the tool once on it. On getPDF, the first file also downloads the engine; you see “Getting the engine” with a percentage for a few seconds, once. Wait until the result appears.
3. Turn the connection off. Wi-Fi off in the system tray (Windows), the menu bar (Mac) or the quick settings (phone), or airplane mode. On a cable, unplug it.
4. Run the tool again on a different file, in the same tab: on getPDF, click Start over (on Inspect: Another file) and drop the next file.
5. Read the result. A local tool finishes: Inspect shows its report on the file, and the other getPDF tools end with a line that says “nothing was uploaded”. A tool that uploads shows an error, spins for ever, or tells you to check your connection.

Why step 2 matters: getPDF does not download its engine when the page opens, only when a file arrives, so people reading a page do not spend about 2.4 MB of data on it. That means “load the page, turn Wi-Fi off, drop a file” fails the first time on our site too, honestly so. Run once, then go offline.

A stronger version: after step 4, close the tab, stay offline, and open the same tool page again. getPDF keeps the pages you have used and the engine on your device, so the page opens and works with no connection at all. A page you have never opened is not kept; offline, the site shows its home page instead, which can open any file.

One more thing you may notice: with the connection off, the small counter message getPDF sends after a job fails quietly. Nothing else is affected.

Test 2: watch the network panel

Every browser on a computer has developer tools, and their Network tab lists every request a page makes, with its address, method and size. You do not need to understand most of it. You need to look for 1 thing: a request that sends your file.

Open the tool page first, then open the panel, because it only records while it is open.

Browser	Open the developer tools	Then
Chrome	F12 or Ctrl+Shift+I (Windows), Cmd+Option+I (Mac); or the 3-dot menu, More tools, Developer tools	Click the Network tab
Edge	F12 or Ctrl+Shift+I (Windows), Cmd+Option+I (Mac); or the … menu, More tools, Developer tools	Click Network; if it is not shown, find it under More tools
Firefox	Ctrl+Shift+E (Windows), Cmd+Option+E (Mac) opens the Network panel directly	Nothing more
Safari (Mac)	First, once: Safari, Settings, Advanced, tick “Show features for web developers”. Then Cmd+Option+I, or Develop, Show Web Inspector	Click the Network tab

Checked on 11 October 2026 against each maker’s own documentation: Chrome DevTools (“Open Chrome DevTools”, “Inspect network activity”), Microsoft Edge DevTools (“Overview of DevTools”, “Inspect network activity”), Firefox DevTools (“Network Monitor”, “Keyboard shortcuts”) and Apple’s Safari developer documentation (“Enabling features for web developers”) with WebKit’s “Network Tab” page.

Then:

1. Keep the list across pages. Tick Preserve log (Chrome, Edge), Persist Logs in the menu at the end of the panel’s toolbar (Firefox), or Preserve Log (Safari).
2. Show the method. Chrome, Edge and Safari hide it by default: right-click any column heading and tick Method. Firefox shows it already.
3. Run the tool on a file of a size you know, say 5 MB.
4. Look for POST and PUT requests. Those are the ones that send data. Click each and open Payload (Chrome, Edge) or Request (Firefox). An upload shows your file name or a large block of data there; in Safari, select the request and read its headers and size.
5. Check the addresses. Every request on a local tool goes to the site itself. Requests to a storage or upload host during the job are the giveaway.

What each of those is, so nothing in your panel is a mystery:

• The page and its files (under /_astro/): the text, layout, scripts and fonts of the page you opened.
• The engine (/vendor/pdfium-2.15.1/pdfium.js and pdfium.wasm): PDFium, the PDF code Chrome also uses, compiled for the browser. The .wasm file is 4.6 MB and travels compressed, about 2 MB. Next to it comes pdf-lib (/vendor/pdf-lib-1.17.1/, about 200 KB compressed), which assembles documents. Both are fetched with the first file you drop, and later answered from your device; Edge marks such rows in its Fulfilled by column, Firefox writes “service worker” in its Transferred column.
• Extras on some pages only, all from the same address: the OCR page fetches Tesseract and the language you pick when you start reading, the HEIC page fetches a photo decoder the first time you drop an iPhone photo, and the editor fetches a font when an edit needs one.
• The counter: 1 POST to /api/count after the job. Click it and open Payload: the whole body is a line like {"tool":"protect-pdf","ok":true,"ms":"lt1s","mb":"lt1"}. That is the tool id, whether it worked, and how long and how big in rough buckets. The privacy page describes it and names the code that sends it.
• Rows starting with blob: or data:, if your browser shows them, are the page reading from the browser’s own memory, for example when it hands you the finished file. They never leave the device.

No Wi-Fi switch? Go offline inside the browser

On a work laptop on a cable, or anywhere you cannot turn the connection off, the developer tools can pretend to be offline for that tab:

• Chrome: in the Network tab, open the throttling menu (it says No throttling) and choose Offline.
• Edge: in the Network tab, open No throttling, then Presets, then Offline.
• Firefox: in the Network panel, open the Throttling menu and choose Offline.
• Safari: we found no offline switch in Safari’s Web Inspector documentation. Turn Wi-Fi off from the menu bar instead.

Then repeat Test 1 from step 4. Switching the real connection off remains the stronger test, because it covers the whole computer, not 1 tab.

Test 3, for the technical reader: the content security policy

Tests 1 and 2 show what a page did today. The content security policy says what the browser will let it do at all. It is a response header, and you can read it in the network panel: click the first row (the page itself), open Headers, and find content-security-policy under the response headers.

getPDF’s says, among other things:

default-src 'self'; connect-src 'self' blob: data:; form-action 'self'

connect-src governs every way a script can send data: fetch, XMLHttpRequest, WebSocket, beacons. 'self' means the site’s own address and nothing else, and blob: and data: are the browser’s own memory. So the browser itself refuses to connect this page to any other host, whether the code asking is ours, a library’s or an attacker’s. There are no third-party scripts, analytics or font services on the page to ask in the first place.

Read it for what it is: the policy proves a file could only ever go to getpdfs.app itself; Test 2 shows that it does not go there either. Together they make “nothing is uploaded” something you checked rather than something you were told.

Who passes

getPDF’s own automated tests do Test 2 on every change to the code: they run every live tool in the engines of Chrome, Firefox and Safari, record every request, and fail if one goes to another address or carries the file or its name. Be clear about what that proves: the tests run next to the deploy, not before it, so a change that broke the rule would be flagged on that change, not stopped from going live. Your own Wi-Fi test checks the site as it is today.

For other sites, here is what they say about themselves, from their own pages, checked on 11 October 2026. These are claims, not our test results; the tests above tell you which hold.

Service	What its own pages say
iLovePDF, Smallpdf, Sejda (website), PDF24 (website), Adobe Acrobat online	Files are uploaded, processed on their servers and deleted afterwards (from 1 to 2 hours; Adobe gives no time). Nothing to test: they say plainly that they upload
PDFgear (online tools)	The home page says the tools work “directly in your web browser”; the tool pages say files are uploaded to and processed on cloud servers in the US. So “in the browser” means nothing to install, not processing on your device
Xodo	“Most tools process files on your device locally”, and files for tools that need an upload are deleted after 1 hour; which tools upload is not said. Test the one you use
PDF24 Creator, Sejda Desktop	Installed apps that process files on your computer; the Wi-Fi test works on them too

An honest upload tool that says so is not the problem. The problem is a site whose words suggest one thing while its network panel shows another, and that is exactly what the 3 tests catch.

The honest part

A local tool removes 1 risk: the copy of your file on someone else’s server. It does nothing about the others, and pretending otherwise would be the kind of claim this page tells you to test.

• Your own device still matters. The downloaded result sits in your Downloads folder. On a shared computer, delete it after use; on a laptop, disk encryption (BitLocker, FileVault) covers a theft.
• Browser extensions are outside the page’s rules. The content security policy binds the website, not the extensions you installed.
• A test shows today’s behaviour. A site can change its code tomorrow. That is why the policy header matters, and why it is worth re-running the test when a site you rely on changes visibly.
• The counter exists. getPDF is not silent: after each job it sends the tool id, success or failure, and 2 rough buckets for time and size. We think that is fair to say plainly, so we do.