How Client-Side PDF Processing Works (In-Browser, No Upload)

“Runs in your browser” is a claim almost every PDF site makes somewhere in its footer. Most of them still upload your file. Here’s what actually has to be true for that claim to hold, and how to check it for yourself in under a minute.

The architecture that makes it possible: WebAssembly

Real PDF manipulation — merging pages, re-encoding images, rewriting an encrypted stream — needs the same low-level libraries native apps use. Browsers can’t run C/C++/Rust directly, but they can run WebAssembly (WASM): those libraries compiled into a binary format the browser executes at near-native speed.

That’s the difference between a client-side tool and a “browser-based” tool that’s really just a nicer upload form. A page with a drag-and-drop box and a progress bar can still be quietly POST-ing your file to a server the moment you drop it. WASM is what lets the actual processing — not just the UI — happen locally.

Why it runs in a Web Worker, not the main thread

Decoding and rewriting a 100-page PDF is real CPU work. Doing it on the browser’s main thread would freeze the page — no scrolling, no clicking, a “tab not responding” warning on anything large. A Web Worker runs that work on a background thread instead, so the interface stays responsive and you get a live progress bar instead of a frozen tab. The file’s bytes are read into memory, handed to the worker, processed, and handed back — all inside your browser process. Nothing about that flow requires or benefits from a server.

What “no upload” actually rules out

If a tool is genuinely client-side, three things follow, and all three are checkable:

• No upload endpoint. There’s no /api/upload or equivalent for the tool to call — because there’s nothing on the other end to call it.
• No processing delay tied to file size and connection speed. A 200 MB file over a slow connection is slow to upload; a client-side tool with the same file is limited only by your device’s CPU, and starts instantly.
• Works offline. After the page has loaded once (and, for a PWA, been cached by a service worker), the tool keeps working with no internet connection at all — because it never needed one to do the work.

How to verify it yourself

You don’t have to take a privacy claim on faith:

1. Open DevTools → Network tab before you run the tool, then process a file. Watch for any request whose payload size tracks your file’s size. If nothing like that appears, the file didn’t leave the browser.
2. Disconnect from the internet, then try the tool again (after the page itself has loaded). If it still works, there’s no server in the loop.
3. Check the page weight, not just the claim. A tool that’s doing real work locally will load a WASM engine — often a lazy-loaded chunk of several hundred KB to a few MB the first time you use that specific tool — rather than a small script that just posts a form.

This is exactly how HivePDF is built: every tool — merge, compress, protect, redact, sign, and the rest — runs through a per-task WASM engine inside a Web Worker, with no upload endpoint behind any of them. For a deeper look at what that means in practice, see are online PDF tools safe and the honest architecture comparison against server-based tools.