Does this PDF tool upload my file? How to check for yourself

The short answer

To tell if an online tool uploads your file, open your browser's developer tools, switch to the Network tab, filter by Fetch/XHR, and use the tool with a test file. An upload shows up as a POST or PUT request whose body is roughly the size of your file. If no request carries a body while the tool works, the file stayed on your device.

The checklist for choosing a safe tool is in a separate guide. This one is the full walkthrough, with what to look for and the traps that make a quick glance misleading.

Set up the Network tab

Any desktop Chromium browser, Firefox or Safari will do; the panels are named almost identically. Safari needs developer features switched on in its settings first.

• Open the tool's page and let it finish loading.
• Open developer tools with F12, or Cmd+Option+I on a Mac, and choose the Network tab.
• Tick Preserve log, so the list survives if the page navigates to a results screen.
• Click the clear button to empty the list. Everything that appears from now on happened because of what you do next.
• Pick a test file of a known, distinctive size, such as a 5MB PDF of nothing important, so an upload is easy to recognise.

What an upload looks like

Use the tool: add the file, press the button, wait for the result. Then filter the list by Fetch/XHR, which hides images, stylesheets and scripts and leaves the requests a page makes from its own code. That is where uploads live.

Click each request and look at the Headers panel. A request method of POST or PUT is the first sign. The Content-Length request header gives the size of the body; one close to your file's size is the file. The Payload or Request tab shows the body itself, and a multipart form containing your file name settles the question.

Watch for these variations, because they are how an upload avoids looking like one:

• Chunked uploads. Large files are often split into many requests of a few megabytes each, so no single request matches the file size. Add up the bodies.
• A different domain. The file frequently goes straight to a cloud storage host rather than the site you are on. Add the Domain column and look for anything unfamiliar.
• WebSockets. Switch the filter to WS. A socket connection shows its traffic in a Messages panel rather than as separate requests.
• The size column. In most browsers it shows the response size, not what was sent. A tiny entry there can still be a large upload.

What is normal to see

A tool that processes files locally still makes requests. It is the direction and the body that matter. GET requests that download scripts, WebAssembly modules, fonts or a PDF engine worker are the page fetching its own code. Some can be large: World of PDF's OCR tool downloads a recognition model of about 6MB from this site the first time you use it. That is a download to you, not an upload from you, and it carries no body.

Analytics is the other common entry. Most sites send small page-view beacons, which are POST requests with a body of a few hundred bytes. We use Google Analytics, so you will see those requests here too. They report that a page was viewed; they never contain a document, and their size makes that easy to confirm.

The airplane-mode test, and its limits

The blunter test is to cut the network. Load the tool, run it once on a throwaway file, then switch off Wi-Fi or enable airplane mode and run it again on the real one. If it works offline, nothing could have been uploaded during that run, because there was nowhere to send it.

The throwaway run matters. Well-built browser tools load heavy libraries only when you first use them, so a genuinely local tool can fail offline simply because its code never arrived. A failure offline is not proof of an upload; success is strong evidence there was none.

It also has a blind spot. A page could, in principle, keep your file and send it once the connection returns. Close the tab before reconnecting, and use the Network tab check when you need certainty rather than a quick reassurance.

How World of PDF tests its own claim

Every tool on this site runs in your browser, and we do not ask you to take that on trust. An automated privacy test drives a set of tools, including merge, split, compress, text extraction, OCR and PDF to Excel, through a real conversion while recording every request the page makes. It fails on any request with a body to this site, any method other than GET or HEAD, and any request to another host except the named Google Analytics endpoints.

A second test loads every live tool page and fails if any of them reach a third party, which is what would catch a font or script quietly swapped for a CDN copy. A separate test installs the site for offline use, switches the network off, and checks that a merge still completes in a tab that never fetched the merging library.

None of that replaces your own check. Run the Network tab walkthrough on any page here and you should see exactly what this article describes: scripts arriving, analytics beacons leaving, and no file.

Frequently asked questions