Why Your PDF Tool Should Run in the Browser, Not the Cloud

Every "drag your file in, get it back processed" site makes the same offer, and for a brochure or a CV it is a perfectly good offer. For a signed contract, a tax return, or anything with a client's name on it, the upload is the part worth thinking about.

The usual framing of this is cloud bad, browser good. That framing is lazy, and it falls apart the moment you ask a tool to do something a browser genuinely cannot. The useful question is narrower: which operations can run locally at all, and does the tool in front of you tell you which side of that line it is on.

Ours does not always run locally either. More on that below, with names.

What an upload actually exposes

The optimistic model is: file goes up, server processes it, result comes down, file is gone. It is optimistic in four separate places.

The file

It lands on someone's infrastructure and its fate is governed by a policy you did not read. Retained for a day, retained until you ask, passed through a quality-control step with a human in it, folded into a training corpus. Free tiers are subsidised by something, and it is not always ads.

The metadata you did not think about

A PDF carries a document information dictionary and an XMP packet, and any library can read both. pdf-lib exposes the fields directly²: title, author, subject, keywords, producer, creator, creation date, modification date.

In a file exported from an office suite, "author" is usually the operating system account name and "producer" names the software and version. You can scrub a document body with great care and still ship your own name, your employer, and the exact minute you wrote it.

Content you believed was removed

Drawing a filled rectangle over text does not remove the text. It adds a shape that happens to sit on top of it, and the original operators stay in the content stream.

We built that file rather than assert it: a page with a settlement figure, a black rectangle over the figure, saved, then reopened and read with PDF.js. getTextContent() returned the line in full, currency and all.

Upload a file like that anywhere and the recipient gets the number.

The request itself

Even a service that deletes your file on the way out keeps request logs: your address, the timestamp, and the filename. If the filename is acme-acquisition-term-sheet-2026.pdf, the file was almost redundant.

What a browser can genuinely do

The old dismissal, that browser PDF tools are toys, has not been true for a while. The real constraint is specific rather than general.

pdf-lib is pure JavaScript and does the structural work: splitting and merging, filling forms, embedding fonts and images, drawing, and reading and setting metadata². It writes an ordinary PDF, not a special browser dialect. Our PDF Merger and PDF Splitter are built on it, and neither sends anything anywhere.

PDF.js is Mozilla's renderer, the one inside Firefox³. It parses and draws, which makes it the right tool for preview, text extraction and exporting pages as images. It is not a creation library.

And then there is the part almost every article on this subject gets wrong.

The password line

pdf-lib cannot encrypt. Its README says so directly: it does not currently support encrypted documents, and the ignoreEncryption option that exists for loading them does not decrypt anything¹.

That single sentence decides a lot. A web page offering to add or remove a PDF password is doing one of two things: shipping a WebAssembly build of a native library, which is a large download the user pays for on first load, or uploading the file. In practice it is nearly always the second.

Compression sits on the same side of the line for a different reason. Real PDF compression means recoding the embedded images and rebuilding the object table, which is an image pipeline, not a page rewriter. WebAssembly builds of Ghostscript or MuPDF can do it in a tab, at the cost of a bundle measured in megabytes, and Ghostscript's AGPL licence is its own conversation before you ship it.

Our own tools, since it would be strange not to say

Some of the tools on this site run in your browser. Some do not, and pretending otherwise in an article about PDF privacy would be worse than saying nothing.

In the tab, nothing uploaded: PDF Merger , PDF Splitter , PDF Rotate Pages , PDF Page Reorder , Image to PDF , PDF to Text , PDF to Image .

Uploaded to our servers in the EU, processed, deleted after 15 minutes: PDF Compressor , PDF Password Protect , PDF Unlock , and the variants explicitly named "Server-Side" for merge, split and rotate, which exist for files the in-browser versions choke on.

Each of those tools states which it is on its own page, and the server-side ones say so in their names. If a document is sensitive enough that this article applies to it, use one from the first list, or a desktop application.

What browsers still do badly

OCR. Turning a scan into searchable text needs a trained model. Browser OCR exists and runs, and on a long document it is slow and the output needs correcting. If you need quality, you need a backend, and then the question is which backend you trust rather than whether to use one.

Signature validation. Verifying a signature means walking a certificate chain and checking revocation, which are network calls by design. This one is not a browser limitation, it is the nature of the check.

Before you upload anything

The whole checklist collapses into one question and one test.

The question: does this file contain a real person's name, money, legal terms, health information, or anything your employer would call confidential? Add to that: is there metadata you would not read out loud, and was anything "redacted" by drawing over it?

The test, for any tool including this one: open DevTools, go to the Network tab, and run it on a small file. An upload is unmistakable, a multipart request roughly the size of your document. Nothing there means the work happened locally. It takes thirty seconds and it settles the question that a privacy policy only makes claims about.

If you do need a hosted service, read the retention policy rather than the marketing page, check the jurisdiction, and find out whether any human ever sees the file.

Why this is structural

A service that holds documents, even for fifteen minutes, is a collection of documents. That is not an accusation against anyone in particular. It is what the architecture is: a database to breach, a bucket to misconfigure, staff with access.

A tool that never receives your file has none of that, and no policy to trust, because there is nothing to have a policy about.

That is the whole argument, and it is why the honest version of it has to include the cases where the browser cannot help. Knowing exactly which four operations force an upload is more useful than believing the browser can do everything, and then quietly uploading a contract to find out it cannot.