Guide
Client-Side vs Upload-Based PDF Tools: What's the Difference
Search for almost any PDF operation and you'll get a mix of two fundamentally different kinds of tool, usually with no indication of which is which. Both might look identical — a drag-and-drop box, a button, a download link — but what happens between those two clicks is completely different depending on which category you landed on.
The two models, plainly
An upload-based tool sends your file to a server. The provider's infrastructure does the actual work — merging, compressing, converting — and sends a result back. This is how the majority of PDF websites have worked since the category existed, because it's also how most web applications in general are built: browser as a thin client, server as the workhorse.
A client-side tool does the opposite: it ships the processing code to your browser, and your browser does the work using its own JavaScript engine, without transmitting the file anywhere. This became practical at scale more recently, as libraries like PDF.js (for rendering and reading PDFs) and pdf-lib (for constructing and editing them) matured enough to handle real documents reliably inside a web page.
Side by side
| Client-side | Upload-based | |
|---|---|---|
| Where your file goes | Nowhere — stays in your browser's memory for the duration of the operation. | Sent over the network to the provider's servers, processed there, then returned. |
| What you need to trust | Only that the page's code does what it says — verifiable with a network inspector. | The provider's security practices, retention policy, and staff access controls. |
| Works offline | Yes, once the page has loaded. | No — requires a live connection for every operation. |
| File size ceiling | Limited by your device's available memory. | Limited by the provider's upload cap and your connection speed. |
| Best suited for | Merging, splitting, rotating, re-saving, converting PDF ↔ image — everyday operations. | OCR at scale, AI summarization, cloud-sync workflows — work that genuinely needs a server. |
Why upload-based tools still dominate
If client-side processing avoids an unnecessary privacy risk, it's fair to ask why most PDF sites still work the old way. Part of it is simple momentum — server-side tools existed first, and rewriting a working product is rarely a priority. Part of it is business model: a server that handles your file is also a server that can log usage patterns, upsell cloud storage, or charge for API access — none of which is possible if the file never reaches it. Neither reason is necessarily malicious, but neither is a reason to prefer that model as a user, either.
When upload-based is genuinely the right call
This isn't an argument that server-side processing is obsolete. OCR across a thousand-page scanned archive, AI-generated document summaries, and workflows that need the result synced straight to cloud storage all require real server-side computing — that's simply more work than a browser tab can take on. The distinction that matters is whether the task at hand actually needs a server. Merging two files, extracting a page range, rotating a scanned image, or converting between PDF and PNG do not — which is exactly why they're well-suited to running entirely on your own device.
Try the client-side approach
All six HerePDF tools run this way — Merge PDF, Split PDF, Rotate PDF, Compress PDF, PDF to Image, and Image to PDF — with nothing ever uploaded.