The Complete Guide to Client-Side PDF Editing
Modern browsers can merge, split, compress, and rearrange PDFs without sending a single byte of your document to a server. Here is how that works, how to verify it, and where the honest limits are.
By the Andromeda PDF Team · Published December 18, 2025 · Updated July 2, 2026
For most of the web's history, "edit a PDF online" meant one thing: upload your file to someone else's computer, let their software process it, and download the result. That model made sense when browsers were thin display layers and all real computation happened on servers. It no longer does. The laptop or phone you are reading this on is more than capable of parsing, rewriting, and re-rendering PDF files on its own — and a mature set of browser technologies now lets websites hand that work to your device instead of taking your document away from it.
This guide is the long version of the story: what client-side processing actually means, the technology that makes it possible, how to check whether a tool really works this way, what you can accomplish entirely in a browser today, and — just as important — what you still can't.
What "Client-Side" Actually Means
Every website you visit is, at minimum, a delivery mechanism for code. Your browser requests HTML, JavaScript, and stylesheets; the server sends them; your browser executes them. The crucial question for a PDF tool is what happens after that initial download.
A server-side tool uses the page it delivered as a shipping label. When you pick a file, the JavaScript on the page transmits it — over the network, to a machine you don't control — where the actual merging or compressing happens. Your document exists, at least temporarily, on someone else's infrastructure, subject to their retention policies, their logging, and their security practices.
A client-side tool inverts this. The server's only job is to deliver the program. Once the page loads, the relationship with the server is essentially over: your file is opened by JavaScript running locally, processed in your browser's memory, and saved back to your disk. The website never receives the document because there is no code path that sends it anywhere. The distinction isn't a policy promise — it's an architectural fact, which is why it can be independently verified (more on that below).
The Technology That Makes It Possible
Browser-based PDF editing isn't one invention; it's the convergence of several web platform features that each solved a piece of the puzzle:
- The File API. When you drop a file onto a web page, the browser exposes it to JavaScript as a local object. Reading a file into memory does not involve the network at all — it is a disk read, not an upload. This single fact is the foundation of everything else here.
- ArrayBuffers and typed arrays. PDF is a binary format, and for a long time JavaScript was awkward with raw bytes. Typed arrays gave the language efficient, direct access to binary data, so a 40 MB PDF can be parsed byte-by-byte at reasonable speed.
- Web Workers. Heavy processing on the main thread freezes the page. Workers move parsing and rendering to background threads, which is why a modern client-side tool can chew through a large document while the interface stays responsive.
- WebAssembly. Decades of battle-tested PDF and image code was written in C and C++. WebAssembly lets that code run in the browser at near-native speed — it is how full rendering engines like PDF.js's image decoders, or ports of compression libraries, become usable on an ordinary web page.
- Mature JavaScript PDF libraries. Open-source projects such as pdf-lib (for creating and restructuring documents) and Mozilla's PDF.js (for rendering them) have spent years handling the format's enormous surface area. Building a reliable client-side tool without them would be a multi-year project; with them, it is engineering rather than research.
None of these pieces is brand new, but the combination only became genuinely practical in the last several years — when WebAssembly support became universal across browsers, when the libraries matured past experimental status, and when average consumer devices got enough RAM to comfortably hold a document, its parsed structure, and the rebuilt output all at once. Server-based tools weren't a conspiracy; they were, for a while, the only viable option. That era is over.
How to Verify a Tool Is Truly Client-Side
"We never upload your files" is a marketing claim until you check it. The good news: unlike a server's deletion policy, a client-side claim is testable from your own chair, in about two minutes, with no special skills.
1. Watch the Network tab
Open your browser's developer tools (F12 or right-click → Inspect) and switch to the Network tab. Load the tool, then clear the log so the page's own assets don't clutter the view. Now select your PDF and run the operation. On a genuine client-side tool you will see no request carrying your file — no POST or PUT with a multi-megabyte payload. A server-based tool, by contrast, shows an upload roughly the size of your document, plainly visible in the size column.
2. Go offline mid-use
This is the most convincing test. Load the page, then disconnect — turn on airplane mode, or use the "Offline" throttling option in the Network tab. Then process your file. If the operation completes with no internet connection, the work demonstrably happened on your machine; there was nowhere else it could have happened. Every Andromeda PDF tool passes this test.
3. Look for upload endpoints
If you are slightly more technical, the Network tab tells you even more. Server-based tools typically talk to API routes with names like /upload, /convert, or /api/process, and you will see the browser request the result file back when processing finishes. On a client-side tool, the download at the end isn't a network download at all — the browser saves a file assembled in memory, which appears as a blob: URL rather than a request to any server. Seeing your "downloaded" file come from a blob URL is a strong signal the whole pipeline ran locally.
4. Read the privacy language critically
Phrases like "files are deleted after one hour" or "transferred over encrypted connections" are tells: deletion and encrypted transfer only matter if your file left your device in the first place. A true client-side tool has nothing to delete. We cover these red flags in more depth in our breakdown of the hidden dangers of free PDF tools.
What You Can Do Client-Side Today
The range of operations that run entirely in-browser now covers nearly everything a typical person does with PDFs. A tour, with the matching Andromeda tool for each:
| Task | How it works in the browser |
|---|---|
| Merge | Pages from multiple files are copied into a single new document structure, preserving fonts and images. |
| Split | Selected page ranges are extracted into separate files without re-encoding their content. |
| Compress | Images are downsampled and re-encoded locally — usually the biggest lever for shrinking scanned documents. |
| Rotate / Crop | Page rotation flags and crop boxes are metadata edits — fast even on large files. |
| Delete pages / Reorder | The document's page tree is rebuilt with pages removed or in a new sequence. |
| Watermark / Page numbers | Text is drawn onto each page's content stream with position, opacity, and font control. |
| PDF ↔ image | Pages are rendered to a canvas and exported as PNG/JPG; the reverse packs images into a new PDF. |
| Private reading | A full viewer for documents you'd rather not open in yet another cloud service. |
These operations also chain naturally, because there is no upload/download round trip between steps. A common real-world workflow — scan a stack of paper, combine the images into one PDF, delete the blank backs of pages, add page numbers, then compress the result for email — runs start to finish in a few minutes without the document ever leaving your machine. With server-based tools, that same workflow means uploading intermediate files four or five separate times, often to different services with different policies.
Two of these deserve special mention. Merging is the most common operation people perform on sensitive documents — loan applications, medical records, legal exhibits — which is why we wrote a dedicated guide to merging PDFs securely. And compression involves real quality trade-offs worth understanding before you click the button; our compression guide explains what actually gets smaller and why.
Honest Limitations
Client-side processing is not magic, and any tool that claims otherwise is overselling. The real constraints:
- Memory is your ceiling. Your file, its parsed object graph, and the rebuilt output must all fit in the browser tab's RAM allowance. A 500-page scanned PDF that runs to hundreds of megabytes can exhaust a tab — especially on a phone. Servers with tens of gigabytes of RAM don't share this constraint. For enormous files, splitting into chunks first often works around it.
- No OCR (yet, practically). Recognizing text in scanned images is computationally heavy, and while in-browser OCR engines exist, quality and speed still lag dedicated server software. If you need a scanned document made searchable, that generally means specialized desktop or server tooling — see our explainer on OCR for what's involved.
- Exotic PDFs can misbehave. The PDF spec is vast — obscure font encodings, unusual color spaces, malformed files that Adobe's own tooling silently repairs. Browser libraries handle the overwhelming majority of real-world files, but a commercial server-grade engine still wins on the weirdest one percent.
- Encrypted files need their password. Client-side tools can open password-protected PDFs only if you supply the password; they cannot and should not bypass document security. Some heavily DRM-restricted files won't open at all.
Why This Matters for Confidential Documents
The privacy case for client-side tools is strongest exactly where PDFs are most used: documents that identify, obligate, or expose someone. Modern data-protection frameworks such as the GDPR are built around a data-minimization mindset — don't collect or transmit personal data you don't need to. A tool that never receives your document is the logical endpoint of that principle: there is no third-party processor to vet, no data-processing agreement to wonder about, no retention window to trust.
The same logic applies to professional confidentiality duties. Lawyers, clinicians, accountants, and HR staff routinely handle documents they are obligated to keep confidential, and uploading such a file to an unvetted web service sits uneasily with that duty even when nothing goes wrong. Keeping the processing on your own device sidesteps the question entirely. (None of this is legal advice — organizations with formal compliance requirements should consult their own counsel — but as a rule of thumb, the fewer machines a confidential document touches, the fewer conversations you need to have.)
The core takeaway: with a server-based tool, privacy is a promise you have to trust. With a client-side tool, it's an architecture you can verify — in two minutes, with the Network tab and airplane mode.
Frequently Asked Questions
If nothing is uploaded, how does a client-side tool work offline the first time?
It doesn't — you need a connection once, to download the page and its code, just as you need one to install any app. After that initial load, the processing itself requires no network. You can load the tool, disconnect, and edit files for as long as you keep the tab open.
Is client-side processing slower than a server?
For typical documents it is usually faster end-to-end, because you skip uploading and downloading the file entirely. A server may crunch a huge file quicker once it has it, but for a 10 MB merge, transfer time dominates — and locally there is none.
Do client-side tools store my files anywhere?
Your file lives in the tab's memory while you work and is released when you close or reload the page. The only copy written to disk is the output you deliberately save. There is no account, no history, and no server-side record that the file ever existed.
Why are client-side tools often free?
Because the expensive part of a traditional PDF service — servers doing the processing and storing the files — doesn't exist. Your device does the work, so the operator's costs are close to static website hosting, which advertising can cover without monetizing your documents.