I measured what four PDF sites do with your file before you click Convert
I build a browser-based PDF suite, so I had an obvious bias and no data. In August I ran the measurement instead of arguing about it.
Protocol. One test PDF — eight pages, deliberately fictional content — dropped into each service's compression tool, in an instrumented browser logging every outbound request: method, destination host, bytes sent. Each receiving host was then resolved to an IP and its operator identified by whois. Anyone can repeat it with DevTools open. Snapshot dated 29 August 2026.
What the network showed.
iLovePDF — file sent on drop, before any click on Compress.
api110.ilovepdf.com/v1/upload→ 57.129.84.252, OVH, Germany.PDF2Go — sent on drop.
www12.pdf2go.com/…/upload-file→ 213.133.98.219, Hetzner, Nuremberg. A Microsoft Clarity session-recording request fires during the same operation.PDF24 Tools — sent on drop, while the interface shows a "Secure" badge.
filetools14.pdf24.org/client.php→ 116.203.221.86, Hetzner, Nuremberg.Smallpdf — not measured. Its native file picker defeated my automation, and I would rather leave a hole in the table than guess.
My own tool, as the control — zero network requests, compression completed.
The part that surprised me isn't that files get uploaded. It's when. On all three measured services the document leaves the machine at drop time, before the user has asked for anything to happen. All of them delete files as promised — but deletion happens after the trip, not instead of it. For a contract, a payslip or a medical report, that distinction is the entire compliance question.
What it changed on the business side.
It turned a feature ("it runs in your browser") into a claim anyone can check in ten seconds: open a tool, cut your Wi-Fi, process a file. It also gave me a buyer I hadn't framed properly before. Firms under professional secrecy — lawyers, trustees, accountants, medical practices — don't need cheaper PDF tools. They need a written processing record for their GDPR / Swiss FADP register, and an install that runs on their own network. That's the paid product. The tools stay free, with no account and no quota, because with no server doing the work there is nothing to ration.
Revenue today: $0. The measurement is three weeks old and the paid offer is younger than that. I'd rather report numbers later than vibes now.
Stack, since it's the usual question: pdf.js and pdf-lib for the PDF work, Tesseract compiled to WebAssembly for OCR, qpdf to WASM for the heavier operations. Everything client-side, installable as a PWA, so it keeps working offline.
Full write-up with the hosts and the protocol: https://vellumpdf.ch/en/etude — the tools themselves: https://vellumpdf.ch/en
Two things I'd genuinely like pushback on:
Is "architecture you can verify" a story a non-technical buyer can hear, or does it only land with people who know what a network tab is?
Everyone tells me to open-source it so the claim is auditable. The bundles are already readable enough to check the no-network claim in DevTools. Is source-available worth the work, or a distraction from the compliance product?
Vellum also launched on Product Hunt this week, if you want the product side: https://www.producthunt.com/products/vellum-10
