Why “no upload” is worth checking
Online PDF tools work in one of two ways. Most send your document to their servers, process it there and send back the result. A smaller group, including FreePDFKit’s core tools, do the work inside your browser tab, so the file never leaves your device. Both kinds of site describe themselves as “secure”, and a privacy page tells you about policy, not about what your browser actually sends. The good news is that you can see for yourself in a few minutes, on any site, with tools already built into your browser.
Always test with a harmless file: a blank document or something you would not mind a stranger reading. The point is to learn how the tool behaves before you trust it with the real thing.
Check 1: watch the Network tab
The Network tab lists every request a page makes, along with how much data each one sends and receives. Browsers show it before encryption, so you can see uploads even on HTTPS sites.
Open it in your browser
- Chrome and Edge: press F12, or Ctrl+Shift+I on Windows and Cmd+Option+I on a Mac, then choose Network.
- Firefox: press Ctrl+Shift+E on Windows or Cmd+Option+E on a Mac to open the Network panel directly.
- Safari: first turn on the developer features in Safari’s settings (the Advanced section), then choose Develop › Show Web Inspector and open Network.
Run the test
- Open the tool page and let it finish loading, then open the Network tab.
- Clear the list so only new requests appear. Leave the filter on All, not just Fetch/XHR: data can also leave as a beacon or an image request.
- Add your test file. Watch the list now, before you press anything: many cloud tools upload on selection.
- Run the tool and download the result.
- Sort by size, or look for requests with the method POST or PUT. Click one to see what it sent (Chrome calls this the Payload tab).
What an upload looks like, and what local processing looks like
| You see | What it means |
|---|---|
| A POST or PUT request about as large as your file, or larger | The file was uploaded. This is how cloud PDF tools work. |
| Several POST requests of a few megabytes each | A large file uploaded in chunks. |
| A request to a storage domain (a bucket or CDN upload address) | The file went to cloud storage, often before processing. |
| Only GET requests for scripts, fonts or a “worker” file from the site itself | The tool downloaded its own code. Your file stayed in the browser. |
| Small POST requests of a few hundred bytes | Usually analytics or error reporting. Open one to check that it does not contain your file or its name. |
Size is the giveaway. A 2 MB PDF cannot travel in a 400-byte request. If no request sends at least as many bytes as your file, the file was not uploaded during that session.
Check 2: the offline test
- Run the tool once, online, with your test file. This lets the page download any code it loads on first use.
- Disconnect: turn off Wi-Fi or unplug the cable, or switch on airplane mode on a phone. In Chrome you can instead pick Offline from the throttling menu in the Network tab.
- Without reloading the page, run the tool again on a test file.
- If it still produces a result, the processing happens on your device. A cloud tool will fail or wait for a connection.
Do not skip the first run. Web apps often fetch the code for a feature only when it is first used, so going offline straight after the page loads can make a local tool fail for reasons that have nothing to do with uploading.
What we saw on FreePDFKit
We ran both checks on our own live site on 5 October 2026, in Chrome, using an automated browser so the results are repeatable:
- Merge PDF with two test PDFs, and Compress PDF with one: while each tool worked, the page made three requests, all GET downloads of its own code from www.freepdfkit.app. The data sent in those requests totalled 0 bytes.
- Offline, after one run online: both tools produced a result with the network switched off.
- Offline, first run: both tools failed, because the processing code had not been downloaded yet. That is the reason for step 1 above.
Away from the tools you may also see a few small analytics requests. FreePDFKit counts page views with Google Analytics and Vercel Analytics and records which tool ran, how many files it produced and how long it took, never the file, its name or its text. The privacy policy lists exactly what is collected.
What these checks cannot prove
- One session, one version. They show what happened when you tested. A site can change, so re-check a tool you rely on from time to time.
- What a server does with an upload. If a tool does upload, the Network tab cannot tell you how long the file is kept or who can access it. For that you have to rely on the provider’s policy.
- Browser extensions. Extensions can read pages and make their own requests. Test in a private window with extensions turned off to see only the site’s behaviour.
- Your own device. A local tool keeps the file off the network, but it cannot protect a document on a shared or compromised computer.
Next steps
If a tool passes both checks, it suits documents you would rather not send anywhere. Try it with Merge PDF, Compress PDF or Protect PDF. For the trade-offs between the two approaches, read browser-local processing versus cloud upload; for specific services, see is iLovePDF safe for confidential documents and the no-upload alternatives compared.
People also ask
Common questions
Can I tell from the website whether my PDF is uploaded?
Not reliably. “Secure”, “encrypted” and “files deleted after one hour” all describe tools that do upload your file. The Network tab shows what actually leaves your browser, whatever the page says.
What does an upload look like in the Network tab?
Usually a POST or PUT request whose size is close to your file’s size or larger, often of type multipart/form-data, sometimes sent to a storage domain rather than the site itself. Large files may be sent as several chunks of a few megabytes each.
Why should I check before pressing the button?
Many cloud tools upload the file as soon as you select or drop it, to save time. Keep the Network tab open from the moment you add the file, not just when you start the conversion.
Does the offline test prove nothing was uploaded?
It proves the tool can do the work without a connection. It does not prove a tool will never send data once you reconnect, which is why the Network tab check matters too. Use both.
Why does a tool fail offline the first time?
Many web apps download the code for a feature only when you first use it. Run the tool once online with a test file, then disconnect and run it again. On FreePDFKit the first offline run fails for this reason; the second works.
Do these checks work on a phone?
The offline test does: run the tool once, switch on airplane mode, and run it again. The Network tab is harder on mobile browsers, so use a desktop browser for that check if you can.