How to check that a "private" PDF tool really doesn't upload your file

A PDF tool can call itself private. You don't have to take its word for it: your browser can show you, in a few minutes, whether the page sends your file anywhere. Here is the check I use, step by step, including what it can and can't prove. Disclosure: I make one of the tools I test with, PDF Guard, and I use it as one example among the tools you can check this way.

Two kinds of "private"

When an online PDF tool talks about privacy, it usually means one of two very different things.

1. We upload your file, then delete it. The document goes to the provider's server, gets processed there, and is removed later, on a schedule the provider sets. That is a real safeguard, but it is a promise about a copy that exists on someone else's machine.
2. We never receive your file. The work happens inside the browser tab, using JavaScript and WebAssembly, and the document never travels anywhere.

Both kinds of tool can put the word "private" on the page. The checks below tell you which one you are actually using.

Check 1: watch the Network tab

While the developer tools are open, Chrome logs the requests the page makes in the Network tab. That makes it the most direct test.

1. Open the tool you want to check, but don't choose a file yet.
2. Open the developer tools: F12 or Ctrl + Shift + I on Windows and Linux, Cmd + Option + I on a Mac. Click the Network tab.
3. Tick Preserve log (newer versions of Chrome call it Keep log), so the list survives if the page reloads, then click the clear button so the list starts empty.
4. In the filter box, type -method:GET, with the minus sign. That hides ordinary downloads and keeps every request that sends something, POST and PUT alike. Don't filter for POST alone: in our test of seven tools (more on it below), most of the uploads were PUT requests, each one going straight to a cloud storage server.
5. Now choose a file. Pick one with a size you know, a few megabytes is ideal, so an upload of that size stands out.
6. Do the job you came for (merge, redact, compress) and download the result.

Then read the list. Click each request that is left and look at two places:

• Headers: under Request Headers, content-length tells you how many bytes the browser sent. A number close to your file's size is a strong sign the file left your computer. Don't go by the Size column in the list: it shows the size of the server's response, so an upload of a few megabytes can appear there as 0.1 kB.
• Payload: what you see here depends on how the page sends the file. For a form upload, Chrome lists the file field as (binary), and View source shows the file name, but not the file's bytes. When the page sends a file straight from your disk as the whole request body, there may be no Payload tab at all. When the page reads the file first and sends its own copy, the tab shows that body, and a PDF starts with the characters %PDF-. In our test of all three cases, content-length showed the real number of bytes sent, so start there.

Two things that confuse people the first time:

• Big downloads are normal. A tool that works in the browser has to download its own code first. The PDF Guard editor, for example, downloads about 2.4 MB of code, styles and fonts, compressed, for one merge. That shows up as large responses. What matters here is what the page sends.
• Some uploads start immediately. In our test, two of the tools began sending the file within a second of it being chosen, before any other click. That is why the Network tab should be open and recording before you choose the file.

Check 2: take the network away (for real)

A tool that sends your file to a server cannot finish the job without a connection.

1. Open the tool and let it load fully. If it is a browser-based tool, use it once with a small file, so its code is cached.
2. Turn off Wi-Fi, or switch on airplane mode. Unplug the network cable if there is one.
3. Load your file and do the work, then download the result.

Use the real switch, not a simulated one. In our own testing, the offline switch of the browser automation tool we used (Playwright) blocked the page's own requests but not those of its service worker, the background script some sites use to keep an offline copy. A simulated offline test can therefore make a tool look more independent than it is.

Read the result carefully, in both directions. If the tool keeps working with no connection, your file did not need to go anywhere for that job. If it stops, that does not prove it uploads: some browser-based tools load parts of their code on demand and fail offline for that reason alone. Ours did, once. Check 1 is the evidence; this one is a quick confirmation.

Check 3: read the page's Content-Security-Policy

Sites can tell the browser which servers their own scripts are allowed to talk to. That rule is the connect-src directive of the Content-Security-Policy header, and the browser enforces it.

1. In the Network tab, clear the filter and reload the page.
2. Click the first request, the page document itself, and open Headers → Response Headers.
3. Look for content-security-policy, and inside it for connect-src.

connect-src 'self' means the browser refuses to let the page's scripts open connections (fetch, XHR, WebSocket, EventSource, beacons) to any origin other than the site's own. That rules out the usual ways a script would quietly send your file to a third party. Form submissions and images are governed by other directives, form-action and img-src, so look at those too.

It is not the whole story, though. 'self' still allows the site's own server, so this header tells you where a page can't send things, not what it does send. Check 1 answers that.

An example: what you will see on PDF Guard

This is the tool I make, so treat this section as one example, not a verdict.

When you run Check 1 on the PDF Guard editor, you will see the app's code arrive from getpdfguard.com on the first visit, including the PDF engine. The work on your document happens in the tab, so there is no request carrying the file. In the editor's code, the requests that carry a body all go to our own site: activating a license key on a paid plan, a timestamp request that carries only a hash when you sign with a trusted timestamp, and a suggestion if you send one. When we merged, redacted and compressed a file on 30 October 2026, the page sent no request with a body at all. One separate feature works differently: a document you choose to send for signature with PDF Guard Sign leaves your device, encrypted in your browser first.

The editor's Content-Security-Policy includes default-src 'self'; connect-src 'self' and form-action 'self', so the browser blocks its scripts from connecting to any other origin.

On 30 October 2026 we also cut the browser off the network completely, with a local proxy refusing every connection, the service worker's included. We did it after the editor had loaded online once and stayed open for a minute, with no earlier use. Merging, redacting and compressing a file all still worked, and so did reopening the editor with no connection and merging there.

Our verification page walks through the Network and Wi-Fi checks step by step, plus a test of whether a redaction really removes the text.

What these checks can't prove

• They cover one session and one version. Web apps can change any time they are updated. A tool that passes today can behave differently next month, so repeat the check now and then.
• Extensions are different. A browser extension can make requests from its own background process, which does not appear in the web page's Network tab. You inspect it separately, from your browser's extensions page (in Chrome, at chrome://extensions, the link next to "Inspect views").
• Small requests can carry information too. Look at payloads, not just sizes. In our test, two tools also sent the file name to a third-party session-analytics or error-reporting service.
• They say nothing about the server side. If a file was uploaded, what happens to it next depends on the provider's own retention policy, which you can only read, not inspect.

What we found when we ran this on seven tools

On 3 October 2026 we gave the same synthetic test file to seven browser-based PDF tools, used without an account, and recorded what each browser sent while merging, redacting or editing, and compressing. Five of the seven sent the complete file to a server in at least one of those operations. In one case the upload began about a second after the file was chosen, on a page that says files are processed in the browser.

The table, the method, the dated evidence and the limits of the test are here: What online PDF editors do with your file. Our own tool is in the table, measured the same way, including the day it failed one of the checks and how it was fixed.

You don't need to trust that page either. Pick a real file, open the Network tab, and spend two minutes watching.

Found something wrong or out of date? Write to [email protected]. We check every report and correct confirmed errors within 7 days.