Client-Side vs Server-Side PDF Tools
When you use a web-based PDF tool, the work has to happen somewhere. The two possibilities — on a remote server, or right inside your own browser — lead to very different outcomes for privacy, speed, and reliability. Knowing which kind you're using tells you a lot about what's happening to your file.
The two models, explained
Server-side processing
A server-side tool sends your file across the internet to the company's computers. Those servers do the work — compressing, merging, converting — and send the finished file back. Your browser is essentially a remote control for software running elsewhere. The defining characteristic: your file leaves your device.
Client-side processing
A client-side tool runs the processing code in your browser using JavaScript and modern web APIs. Your file is read into local memory, manipulated by your own device's processor, and the result is handed back to you as a download. The defining characteristic: your file never leaves your device.
Side-by-side comparison
| Factor | Server-side | Client-side |
|---|---|---|
| Privacy | File is uploaded; you rely on their policy | File stays local; nothing to leak |
| Speed | Upload + queue + process + download | Starts instantly; no upload wait |
| Offline use | Requires a connection | Works once the page is loaded |
| File-size limits | Often capped to save bandwidth | Limited only by your device's memory |
| Heavy lifting | Powerful servers handle huge jobs | Depends on your device's power |
| Verifiability | You must trust the provider | Check the Network tab yourself |
Where each one shines
Neither model is universally "better" — they have genuine trade-offs.
- Server-side can be the right choice for extremely heavy jobs that would strain a phone or old laptop, or for specialized conversions (like OCR on huge batches) that need serious computing power. The price is uploading your data.
- Client-side wins decisively on privacy, instant startup, offline capability, and the absence of upload caps. The limit is your own device: a 500-page scanned monster might tax a low-end phone.
The privacy difference is structural
With a server-side tool, privacy is a promise — you trust the company to delete your file. With a client-side tool, privacy is an architecture — the file is never sent, so there's nothing to delete, leak, or subpoena.
How to tell which one you're using
You can check directly. Open your browser's developer tools (F12 on most desktop browsers), switch to the Network tab, clear it, and run the tool on a file. If you see a large upload request carrying your file's data, it's server-side. If you see no such upload — the tool just works and produces a download — it's client-side.
Why the browser can do this now
Client-side PDF processing wasn't really practical until relatively recently. It depends on a handful of browser capabilities that matured over the 2010s: the File API for reading local files without a server round-trip, the Canvas API for rendering page content, WebAssembly and fast JavaScript engines for running compression algorithms at native-like speed, and enough memory headroom in modern devices to hold a document in RAM while it's manipulated. Put together, these let a browser do work that used to require a dedicated server — which is precisely why "does this really run locally?" is a fair question to ask about any tool claiming to.
Why CrunchyPDF is client-side
We chose the client-side model on purpose. For the everyday PDF tasks most people need — compressing for email, merging a few files, splitting out some pages, converting images — modern browsers are more than capable, and there's simply no good reason to ship someone's private contract to a server first. The result is a toolkit that's fast, works on a plane, has no arbitrary size cap, and keeps your documents where they belong: with you. Learn more on our About page.