What browser-based PDF tools cannot do, and why nobody says so

Plenty of sites will tell you their PDF tools run in your browser and your file is never uploaded. Fewer will tell you which operations can't work that way at all.

That second list is more useful, because it tells you when a "private, browser-based" claim can't be true — and gives you something concrete to check before you trust it.

We build DocVelora on pdf-lib, the same JavaScript library most browser-side PDF tools use. Here is what we hit when we pushed it, including the parts that made us drop features we'd planned to ship.

Passwords: we tested this and it does not work

pdf-lib has no encryption support. Not a missing option — the capability isn't there. So no browser-only tool can add a password to a PDF.

Removing one is where it gets interesting, because pdf-lib has an ignoreEncryption flag that looks like it should do the job.

It doesn't. That flag suppresses the error thrown when the library loads an encrypted file. It does not decrypt anything. We tested it against two files: one with owner restrictions, and one with a genuine open password. Loading and re-saving each through pdf-lib produced a corrupted PDF both times.

So a browser-only "unlock PDF" tool has three options: upload your file to a server, hand back a broken file, or not exist. We chose not to exist. There is no Protect PDF or Unlock PDF on this site, and there won't be until we can do it without uploading your document.

If you find a tool claiming to remove PDF passwords entirely in your browser, that's the claim worth testing first.

Compression: possible, but usually not the way it's sold

"Compress PDF in your browser" is technically achievable and frequently misleading.

pdf-lib can't re-encode the image streams inside a PDF, which is where nearly all the size in a large file lives. The workaround is to render each page with pdf.js, re-encode it as a JPEG, and rebuild a new PDF from those images.

That works on scans. On a text document it's destructive: your searchable, selectable text becomes a flat picture of text. You lose search, copy-paste and screen-reader access, and for many text PDFs the output is larger than the original.

We haven't shipped a compression tool because we haven't found a version of it we'd be comfortable describing accurately on the button. Checking the page setup first is often more useful anyway — a lot of oversized PDFs are oversized because of what went into them, not how they were saved.

OCR and format conversion: real server work

Reading text out of a scanned page needs models too large to ship to a browser. Converting a Word document to PDF means interpreting an enormous, quirky format with decades of edge cases.

Word to PDF is the one tool here that uploads your file. It runs server-side, converts, and deletes the file immediately after you download the result. We say so on the tool page, not only in the privacy policy, because a disclosure you have to go looking for isn't much of a disclosure.

Two things we found building it, for what they're worth: PHPWord's DOCX reader silently discards list formatting when it reads a document back, so bullets and numbers vanish unless you inject them beforehand. And Devanagari text renders as invisible boxes unless the font is switched at runtime based on the script detected in the file. Neither is documented anywhere obvious. Both took real files to discover.

What genuinely doesn't need a server

A large set of operations only rearrange a PDF's existing structure. They never need to interpret the content, only the container — so there is no technical reason to upload your file for any of them:

• Merge PDFs into one document
• Split a PDF into several files
• Extract pages into a new file
• Remove pages you don't need
• Reorder or organize pages
• Rotate pages that scanned sideways
• Add page numbers
• Add a text watermark
• Crop margins
• Read and edit metadata
• Check page sizes and orientation
• Turn images into a PDF

Every one of those runs in your browser here. When a site uploads your file to do one of them, that's a decision about their architecture, not a constraint.

How to check any tool in about a minute

Two tests, neither requiring you to trust anyone's copy:

Load the page, then disconnect from the internet. If the tool still works offline, the processing is local. If it fails, your file was going somewhere.

Watch the Network tab. Open developer tools (F12), switch to Network, then run the tool. A local tool sends no request carrying your file. A server tool sends a POST roughly the size of your document at the moment you click.

One thing worth adding, because it's easy to miss: a tool can process your file locally and still load third-party trackers on the page. The file staying put doesn't mean the visit is private. Check what else the page loads while you're already in the Network tab.

Why sites don't publish this list

Because a limitations page doesn't sell anything. It's easier to describe what your tools do and stay quiet about the boundary.

We'd rather publish it, for a practical reason as much as a principled one: if we tell you where the edges are, the claims we do make become checkable. You can verify every item in the list above yourself in under a minute.

Our privacy page breaks this down tool by tool, and there's a full list of what's here if you want to start somewhere.