How Client-Side PDF Processing Works

For most of the web's history, "process this file online" meant one thing: upload it to a server, let a computer somewhere else do the work, and download the result. That assumption is now out of date. A modern browser is a genuinely powerful computer, and it can open, edit, and re-save a PDF entirely on your own machine — no upload required.

This article explains, in plain terms, how that works, what makes it possible, where its limits are, and — most usefully — how you can verify for yourself whether a given website is doing the work on your device or quietly shipping your file off to a server.

The old way: server-side processing

In the traditional model, the browser is basically a courier. Here is the round trip:

1. You pick a file. Your browser packages it up and uploads it over an encrypted connection to the company's server.
2. The server runs the actual PDF software (merge, compress, OCR, convert) on its own hardware.
3. The finished file is sent back down to your browser, and you download it.

This works well and can handle very large jobs, because servers are powerful. The privacy cost is structural, though: your document physically leaves your device and exists, at least briefly, on a computer you do not control. We covered what that means in practice — and what the big providers' policies actually say — in Are online PDF tools safe? What actually happens to your files.

The new way: everything happens in your browser

Client-side processing flips the model. Instead of sending your file to the software, the software comes to your file. When you open a client-side tool, your browser downloads a small application (JavaScript, and often WebAssembly) once. From then on, the work happens locally:

1. You pick a file. The browser reads it into memory using the standard File API — this does not send it anywhere; it just makes the bytes available to the page's code.
2. That code manipulates the PDF right there on your device — reordering pages, compressing images, adding a signature, whatever the tool does.
3. The result is offered back to you as a download, generated locally in the browser.

At no point is there an upload step. The file goes from your disk, into your browser's memory, and back to your disk.

What makes this possible: JavaScript and WebAssembly

Two browser technologies do the heavy lifting:

• JavaScript handles a surprising amount on its own. Libraries like pdf-lib (for editing and assembling PDFs) and Mozilla's pdf.js (for rendering pages) run natively in every modern browser.
• WebAssembly (WASM) handles the rest. WASM is a low-level format that lets code written in languages like C, C++, and Rust run in the browser at near-native speed. This is the breakthrough: the same battle-tested PDF and image libraries that used to require a server can now be compiled to WASM and executed inside the browser's secure sandbox. Optical character recognition (OCR), for example, can run locally through a WASM build of a mature engine.

Because WASM runs in the browser's sandbox, this code can touch the file you handed it — but it cannot silently reach into the rest of your computer. You get desktop-class capability with browser-class safety. (This, incidentally, is the exact stack ContinuePDF is built on.)

The performance gap between "upload, process, download" and "process locally" has largely closed for everyday PDF tasks. For most jobs, doing it in the browser is not a compromise — it is just as fast, and more private.

Why this matters for privacy

The privacy benefit of client-side processing is not a policy or a promise — it is a consequence of the architecture:

• Nothing to breach. If your file was never uploaded, there is no server-side copy for an attacker to steal.
• Nothing to retain. There is no "we delete files after N hours" question, because the file never arrived on a server in the first place.
• Nothing to hand over. Data that only ever existed in your browser cannot be produced in response to a legal request or an insider.
• It works offline. Because the work is local, a true client-side tool keeps functioning even with no internet connection after the page has loaded — which is also the basis of the test below.

The honest trade-offs

Client-side processing is not magic, and it is not always the right choice. Being straight about the limits:

• Your device does the work. Very large files or huge batch jobs are bounded by your machine's memory and CPU rather than a beefy server. On a modern laptop or phone this is rarely an issue for normal documents, but a 2 GB scan is a different story.
• First load downloads the engine. The WASM component is fetched once (then cached). That initial download is the cost of never having to upload your files afterward.
• A few tasks still favor servers. Some heavy or exotic conversions are genuinely easier server-side. A good client-side tool is honest about what it does and does not do locally.

How to check whether a site uploads your files

This is the part worth bookmarking. You never have to take a website's privacy claim on faith — including ours. Here are three checks, from easiest to most technical.

1. The airplane-mode test (easiest)

1. Open the tool's page and let it finish loading.
2. Disconnect from the internet — enable airplane mode, or turn off Wi-Fi.
3. Now try to process a file.

If the tool still works with no connection, the processing is happening on your device — a server tool would have nothing to talk to. If it fails or hangs, it needed to reach a server (which usually means an upload).

2. The network-tab test (definitive)

1. Open your browser's developer tools (F12, or right-click → Inspect) and select the Network tab.
2. Optionally filter to Fetch/XHR, and tick "Preserve log."
3. Perform the PDF operation and watch the list of requests.
4. Look for an outgoing request — typically a POST with a request body roughly the size of your file, often sent as multipart/form-data. If you see your file's worth of data going out, it was uploaded. If the only activity is the page's own assets loading, it was processed locally.

3. Read the privacy policy (corroborating)

Search the policy for words like "upload," "server," "store," "retention," and "delete." A server-based tool has to explain how long it keeps your files and how it protects them on its infrastructure. A genuinely client-side tool has comparatively little to say there, because it does not receive your file.

The bottom line

"Online" no longer has to mean "uploaded." Thanks to JavaScript and WebAssembly, your browser can do serious PDF work entirely on your device, so your documents stay with you by design rather than by promise. And you do not have to trust anyone's marketing about it — the airplane-mode and network-tab tests let you verify exactly where your file goes in under a minute.

Want to see it in action? Try it on a real document with Merge PDF, Compress PDF, or the PDF editor — all client-side. And for the practical privacy side of the story, read the companion piece: Are online PDF tools safe? What actually happens to your files.