How to Check If an Online PDF Tool Uploads Your Files (5-Minute Test)

Published September 12, 2026 · 7 min read

You have a contract, an ID scan, or a financial statement, and you need to merge, compress, or convert it. An online tool is convenient — but "convenient" usually means your file travels to someone else's server first. The good news: you can find out, in about five minutes and without sending any real document, whether a given tool uploads your file or processes it entirely on your device.

Why the question matters

Online PDF tools fall into two architectural camps, and the difference between them is everything:

Server-based tools work by uploading your document to the provider's server, running the operation there, and handing you a link to download the result. The provider typically promises automatic deletion after a few hours, and many are trustworthy — but your file still crosses the network, passes through their storage, and is subject to their security practices and their jurisdiction. For a grocery list that is a non-issue. For a signed contract, a passport scan, or payroll data, it is a real decision.

Client-side (local) tools do the opposite: the page loads the processing software — JavaScript and WebAssembly document engines, the same technology used by Adobe's own browser-based PDF services — into your browser, and your file is processed inside your tab's memory. Nothing about the document leaves your device, because there is no network step in the data path at all. The tool cannot leak your file by accident; the only things the site can see are page views and, if you enable analytics, the events you agree to share.

Most users cannot tell the two apart from the interface — both show a dropzone, a progress bar, and a download. The Network tab can.

The 5-minute test, step by step

You will do this in Chrome, Edge, or Brave (all use Chromium's DevTools). Firefox's version works too; the panels are named slightly differently.

Reading the Network tab

Three patterns matter:

Pattern 1 — an upload request (server-based)

A server-based tool will show a request to its own domain or to a storage service (commonly S3, GCS, or an upload API path like /api/upload or /process), with a POST method, a large request payload of several hundred KB to MB, and your file name in the request body, the query string, or the pre-signed URL. Click the request and look at the Payload sub-panel: if you see your file's bytes or name there, your document just left your machine. That is the whole answer — the tool is server-based.

Pattern 2 — only local activity (client-side)

A truly local tool shows no new network traffic at all while the file is being processed. The progress bar is driven by JavaScript running in your tab. The list in the Network tab stays exactly as it was after the page loaded: fonts, scripts, CSS — static assets, nothing new. If you selected a 5 MB file and the log gained nothing, the 5 MB never crossed the network. Your download at the end is produced from your tab's memory by the browser's download API, which also leaves no upload trace.

Pattern 3 — the honest exception (model downloads)

One client-side pattern that still shows network traffic: an OCR tool on its first run downloads a language model file (a few MB, from a public CDN such as the Tesseract project's tessdata host). That request contains no part of your document — it is the same public model file every OCR browser app fetches. How to tell the difference: the download's URL is a fixed model path (something like eng.traineddata.gz), its size is constant regardless of your file, and it happens before or during engine setup, not when your file is read. Your document bytes will not appear anywhere in the log. A responsible tool tells you about this first-run download on its page; PDFZaap's OCR tool page states it, and the privacy policy does too.

The second check: reading the page's code

If you want more confidence than one test run gives, look at what the page actually ships. In DevTools, go to the Sources tab (or use ⌘ + Option + U for page source) and search for the tell-tale calls:

• fetch(, XMLHttpRequest, or axios.post with a URL pointing at the site's own API — followed by FormData or file.arrayBuffer() — is an upload path.
• References to pdf-lib, pdf.js (Mozilla's PDF engine), or a .wasm WebAssembly file loaded into the page, combined with URL.createObjectURL for the download, is a local processing path.
• Local tools never need a file field in a form. If the only way to "submit" your PDF is to hand it to a form action that POSTs somewhere, it goes over the wire.

This check is not exhaustive — obfuscated code can hide things — but combined with the Network test it is about as far as a non-malicious-tool vetting goes from a browser.

How PDFZaap behaves under this test

If you run the test on any PDFZaap tool page you will see Pattern 2: no new requests while the file is processed. The processing libraries (pdf.js, pdf-lib, Tesseract.js for OCR) are loaded with the page, and the file is read, processed, and re-exported inside your tab. The only documented network activity on first use of the OCR tool is the Pattern 3 model download. You can verify all of it yourself with the steps above — that is the point of the architecture, and it is why the privacy explainer walks through the same test.

Is server-based always wrong?

No. If the document is not sensitive — a public brochure, an open-source paper, a photo of a recipe — a server-based tool is fine, and some capabilities are genuinely easier to do well server-side (certified PDF/A validation, layout-perfect PDF-to-Word conversion of complex documents, for example). The honest framing is a risk decision: match the tool's architecture to the sensitivity of the document. The five-minute test simply makes sure the decision is informed rather than assumed.

Quick checklist

• Open DevTools before selecting the file; clear the Network log.
• Use a throwaway file with a distinctive name.
• No new requests during processing → local. Upload request with your file's bytes or name → server-based.
• A fixed-size model download (OCR) is a documented exception, not an upload.
• Cross-check the page's source for upload calls vs. local engines.
• Match the architecture to the document's sensitivity — and keep the original file until the output is verified.

Frequently Asked Questions