Why a browser-based PDF tool is safer than an upload site

Two architectures, three big questions

Every online PDF tool is one of two architectures: it does the work on a server somewhere (we'll call this upload-based) or it does the work in your browser tab (we'll call this browser-based). When you drag a PDF onto a tool, three things matter: where the file goes, where the file lives, and who can see it on the way.

Upload-based tools send your file across the internet to a server you don't control, store it for some amount of time, do the work there, send a result back, and (in the best case) delete the original. Browser-based tools do all the same work, but inside your browser tab, on your own device. The file doesn't travel. There's no server-side copy to delete because there's no server-side copy.

When the difference actually matters

Most PDFs aren't sensitive — a vacation receipt, a meme, a conference brochure. For those, upload-based and browser-based are functionally identical, and the upload-based version might even be faster (servers are big computers). But some PDFs are sensitive. These are the ones people care about most:

• Personal records — passports, driving licenses, medical reports, insurance forms.
• Financial records — bank statements, tax returns, payslips, mortgage paperwork.
• Legal documents — contracts under negotiation, severance agreements, NDAs.
• Work product — internal memos, drafts, anything covered by an NDA you signed.

For these, "we delete after 1 hour" is a promise you can't verify. Browser-based removes the question: the file never arrives anywhere it could be retained.

The threat model, honestly

Browser-based isn't a silver bullet. It rules out one specific class of threat — a third party gaining access to a server with your file on it. There are threats it doesn't help with:

• Your own device is compromised. If something malicious is already running on your laptop, no web tool — browser-based or upload-based — can save you.
• Browser extensions you've installed. An extension with broad permissions can see what's in your tab, including the bytes of the PDF you just dropped. Audit your extensions periodically.
• The recipient of the result. If you protect a PDF in your browser and then email it to someone, your privacy promise ends at the send button. The recipient handles it however they handle it.

What browser-based gives you is one fewer hop in the chain — the server you'd otherwise be sending the file to. For a lot of people, that hop is the riskiest one.

A side-by-side comparison

No architecture wins every row. Browser-based is better for everyday and sensitive PDFs; upload-based is better for OCR-heavy or batch workflows. Both are fine for vacation receipts.

What "in your browser" really means

The browser tab you're reading this in is a small, well-sandboxed computer. It has its own memory, can run compiled WebAssembly modules at near-native speed, and can read and write files that you choose to share with it. When you drop a PDF onto a browser-based tool, the tool's JavaScript reads the bytes from the file picker, hands them to a WebAssembly library compiled from a real PDF processing toolkit (in our case, libraries like pdf-lib, pdfjs-dist, qpdf-wasm), gets a new set of bytes back, and shows you a download link.

No network call carrying your file. No server logs noting that you visited at 2am with a PDF named divorce-draft-v3.pdf. No retention policy to read. Just bytes in, bytes out, all on your device.

You can verify this yourself. Open DevTools → Network, filter by "Fetch/XHR", drop your file, and run the conversion. You'll see the page resources load once at the start and nothing else.

Where browser-based has real limits

We'd rather tell you about the rough edges than have you discover them mid-task:

• OCR quality. The best OCR systems use models that are gigabytes in size. We won't ship a gigabyte to your browser tab. For high-stakes OCR, our future server-side OCR will outperform anything in-browser.
• Truly huge files. A 500 MB PDF will exhaust browser memory before it finishes. Server-side tools running on machines with 64 GB of RAM don't have that problem.
• Old browsers. WebAssembly works in every modern browser (last ~5 years). If you're on something older, browser-based tools may not run; upload-based ones will.
• Mobile data. The page is bigger than an upload-based equivalent because the processing libraries ship with it. On a slow mobile connection, the first load can feel slow. After that, you're set.

How to choose

For sensitive PDFs and everyday tasks (merging, signing, filling, redacting, watermarking, password-protecting): pick browser-based. For OCR-heavy or batch jobs on non-sensitive files: upload-based is fine. For anything in between, ask yourself: would you be comfortable if a stranger read this specific PDF? If no, go browser-based.

If you'd like to try ours, every tool in our toolkit is browser-based. Start with the homepage, pick the tool you need, and drag your file onto the page. No signup, no upload, no subscription. The page does the work.