Claims such as "secure", "private" and "files deleted automatically" are common on PDF sites. They do not tell you whether your file is uploaded. A site can be careful and still upload it, and a site can claim to be local and not be. This guide shows two tests you can run in a few minutes on any PDF website, using only your browser.
Use a harmless test file for this, such as a blank PDF or a public document. Do not test with something private.
Test 1: watch the Network tab
Every modern desktop browser has developer tools that show everything a page sends and receives. If a file is uploaded, you will see it.
- Open the PDF tool page in Chrome, Edge or Firefox on a computer.
- Press F12 (or Ctrl+Shift+I, or Cmd+Option+I on a Mac) and click the Network tab.
- Tick Preserve log so entries do not disappear if the page changes. Click the clear button to empty the list.
- Choose your test file and run the tool, for example merge, then download the result.
- Look through the new entries. Sort by Size or look at the Method column.
What to look for:
- Requests with the method POST or PUT. Uploading a file normally uses one of these.
- A request roughly the size of your file. The Size or Transferred column and the request payload show how much was sent. A 2 MB test file should produce a request of about 2 MB if it is uploaded.
- Requests to a different host from the site you are on, such as an api or upload address. Click one and read the Request headers and Payload tabs. Multipart form data or a long block of binary suggests a file.
- Requests with Fetch/XHR or WebSocket in the Type column. Use the filter buttons at the top to show only those.
What a local tool looks like: when you add and process the file, nothing new appears except small requests, or no new requests at all. You will see page files, scripts and library files being loaded, which is normal, because the site has to deliver its code. Those are downloads to you, not uploads from you. Compare the sizes: a library downloaded might be several megabytes, but it comes in the Response, not in the Request payload.
There is one catch. Some tools load a library the first time you use them, such as an OCR engine. That appears as a download after you pick a file. Check that the request is a GET for a script or data file, not a POST carrying your document.
The same approach works on DocPro. On its tool pages you will see script, WebAssembly and font files load from docpro.pro. If you are signed in, you may also see small calls to the account service to check your plan. The document is not in any of them.
Test 2: the offline test
This is the easiest test and needs no developer tools.
- Open the PDF tool page and let it load fully.
- Open the tool you want to use and, if it loads extra files, use it once so everything is cached. A tool that downloads its engine on first use needs this step.
- Turn on airplane mode or disconnect from Wi-Fi. In desktop Chrome you can instead open DevTools, go to Network and set the throttling menu to Offline.
- Without reloading the page, add your test file and run the tool.
- See whether it still produces a result.
If the tool works with no connection, it cannot have uploaded your file, because there was nowhere to send it. If it shows an error such as "network error" or spins forever, the processing depends on a server.
A failure is not proof of bad intent. A tool might work locally but check licences or load code after you click. But success is strong proof that the file stays local.
Test 3: read the policy for the right words
A privacy policy or security page tells you what the company says it does. Look for:
- Words like retain, store, delete, hours, days. A site that uploads should say how long it keeps files.
- The words processed locally or in your browser. A site that does local processing will say so plainly and often in the product description.
- A list of third parties: hosting, analytics, advertising, payments.
- Where the servers are, and which company is responsible.
- Whether any account or storage features keep your files longer.
Policies are statements, not proof. Use them to decide whether the Network and offline results match what the site says.
Red flags
- No stated retention period and no way to delete files.
- A claim like "we never look at your files" with no explanation of where processing happens.
- The tool needs you to log in or give an email address before it will process a file that should not need one.
- Many unrelated requests to ad or tracking hosts that fire as soon as you add a file.
- Download pages that push you to install other software before you get your result.
- Impersonation domains: slight misspellings of famous PDF site names, or ads that look like tool buttons.
Mobile devices
You can run the offline test on a phone with airplane mode. The Network tab is harder to reach on mobile, so if you want it, connect the phone to a computer and use remote debugging, or test the same site on a desktop browser.
What these tests cannot tell you
They show what a page does right now. A site could change its code tomorrow. They also cannot see what happens on a server after an upload. For regular use, keep your trust proportional: use on-device tools for sensitive files, and treat anything else as a convenience. Read why private documents deserve extra care and how on-device tools work for more.
Try it on DocPro: open Merge PDF, go offline after the page loads, and merge two test files. If it works, nothing was uploaded.