Measured 2026-08-11 · reproducible · 20 tools

We measured 20 online PDF tools. Twelve upload your file.

We handed an identical 3.00 MB PDF to 20 online PDF tools and counted the bytes that left the machine. Of the 13 tools we could measure, 12 transmitted the entire file to a server. Encryption hides what is inside an upload; it cannot hide that one happened. The method is published below as runnable code, and Filevane is in the table under the same test.

The results

“Bytes sent” counts only traffic after the file was handed to the page, so page load, fonts, ads and analytics are excluded. A tool that processes in your browser has nothing to send no matter how large the file is.

What this does and does not show

It shows that a file was transmitted, and to which host. It does not show that any company retains your file, reads it, or does anything improper with it. Most of these services state that uploads are deleted after a period, and we have no evidence to the contrary. The distinction that matters is simpler: a deletion policy is a promise about something that already happened, while a file that was never sent needs no promise at all. For a confidential contract, a medical record or a passport scan, that difference is the whole decision.

The seven we could not measure

These are failures of our test, not findings about the tools. None of them should be read as private, and none as uploading.

• Adobe Acrobat online — The page would not load from our test network across three attempts (HTTP/2 protocol error). The hostname also resolved to an address outside Adobe's published ranges, which suggests DNS interference on our connection rather than anything about the service.
• AvePDF — DNS resolution failed repeatedly from our test network; the page never loaded.
• LightPDF — The page loaded and accepted the file, but we could not confirm the tool ever started, so the absence of an upload proves nothing.
• Xodo — The page loaded and accepted the file, but we could not confirm the tool ever started. Outbound traffic in the window was third-party telemetry, not the document.
• PDFgear — We could not confirm the tool ever started.
• OnlineConvertFree — No file input could be located automatically; this one needs a manual pass.
• DocuPub — The file was accepted but we could not confirm the tool ever started. This row is the reason the 'did it actually run' check exists: without it, this tool would have been recorded as processing locally.

Download the data

Released under CC BY 4.0. Reuse it, re-run it, or contradict it — a table nobody may copy is a table nobody can check. The files are generated from the same source as the table above, so they cannot disagree with it.

• pdf-upload-audit-2026-08-11.csv — one row per tool: verdict, bytes sent, destination host, evidence.
• pdf-upload-audit-2026-08-11.json — the same rows with the column schema inline.
• pdf-upload-audit-README.txt — method, the three verdict rules, and what each column means.

The method generalises. It is written up as method 6 of the verification guide so it can be pointed at any site, including this one.

Method

1. A real Chromium browser is routed through a local counting proxy, which tallies bytes sent to each destination at the transport layer. It tunnels traffic untouched — nothing is decrypted, inspected or stored.
2. Each tool’s page is opened normally and any cookie banner dismissed. Byte counters are snapshotted at the exact moment before the file is handed over, so only what follows can contain the document.
3. The test file is a valid 3.00 MB PDF padded with random bytes. Random matters: incompressible data cannot be shrunk in transit, so a 3 MB upload measures as 3 MB.
4. A tool is recorded as uploading only if at least half the file reaches a named host. It is recorded as local only if outbound bytes stay near zero and we can independently confirm the tool actually ran.
5. One run per tool — the same footprint as a single visitor. Each run is dated.

Why point four exists

Because without it this page would have been wrong. In an early run, two tools showed near-zero outbound traffic and were classified as processing locally. Neither did. Our script had simply failed to start them — and a tool that never runs looks exactly like a tool that runs in your browser. One of the two, PDFSimpli, was subsequently measured sending the complete file to Microsoft Azure storage. Publishing that first result would have handed a privacy endorsement to a service that uploads your document, which is a worse failure than any finding on this page.

That is why “not established” is a published verdict rather than a quietly dropped row. A study that only ever finds what it set out to find is not a study.

Check it yourself in thirty seconds

1. Open any online PDF tool, including ours.
2. Press F12 and select the Network tab.
3. Filter to Fetch/XHR, then add a large PDF and run the tool.
4. Watch for a request the size of your file. If you see one, the document left your machine. If nothing that size appears, it did not.

The same check applied to Filevane is documented on our privacy proof page, which also publishes the Content-Security-Policy header that makes uploading impossible rather than merely against policy. Background on the two architectures is in why browser-based tools are safer and do online PDF tools upload your files.

Corrections and right of reply

If you operate one of these services and this measurement is wrong, or your architecture has changed since 2026-08-11, tell us and we will re-run the test and publish the result, including if it contradicts this page. Every row is dated because any of them can go out of date.

Questions

How can you tell whether an online tool uploads your file?

Measure the bytes leaving your machine. Encryption hides what is in an upload but never how large it is, so a tool that processes on a server must move the whole file and a tool that processes in your browser has nothing to send. We hand each tool an identical 3 MB file of random data — random specifically so it cannot be compressed in transit — and count bytes sent per destination from the moment the file is selected.

Which online PDF tools upload your files?

In this measurement, twelve of the thirteen tools we could measure transmitted the entire test file to a server: Smallpdf, iLovePDF, PDF2Go, Sejda, Soda PDF, PDF Candy, PDF24, FreePDFConvert, DocFly, TinyWow, CleverPDF and PDFSimpli. Each destination host is named in the table. Seven further tools could not be measured and are reported as untested rather than as private.

Does uploading a PDF to an online tool mean the company keeps it?

Not necessarily, and this measurement does not claim that. It establishes only that the file was transmitted. What happens next — retention, logging, backups, jurisdiction — is governed by each company's own policy, which you cannot verify from outside. That gap between 'we delete it later' and 'it was never sent' is the entire point of the distinction.

Why are some tools listed as not established?

Because we could not obtain a valid measurement — the page would not load from our network, or we could not confirm the tool ever started. Silence is not evidence: a tool we failed to start looks identical to one that processes locally. Two tools in this set initially read as local for that reason, and one of them was later measured uploading the full file. Reporting those as private would have been the most damaging error this page could make.

Can I reproduce this audit myself?

Yes, and you should. The measurement script is published in the Filevane repository, and the manual version takes thirty seconds: open a tool, press F12, select the Network tab, add a file, and watch for a multi-megabyte request. You do not have to trust this page to check its central claim.