Most online PDF tools work the same way. You click "merge" or "compress," your file travels across the internet to a server somewhere, gets processed, and comes back to you. Simple, effective — and a massive privacy blind spot.
Think about what you actually put in PDFs. Tax returns. Legal contracts. Medical reports. HR documents. And we've all just been uploading them to random websites without a second thought.
I built Aservus to fix this. Here's the technical story of how we moved PDF processing entirely into the browser using WebAssembly — and what we learned along the way.
Why PDF tools historically needed servers
PDF processing isn't a simple operation. Under the hood, merging two PDFs means parsing binary file structures, handling font embeddings, managing cross-reference tables, and rewriting the output as a valid PDF spec document.
Historically this required native C or C++ libraries — things like libpoppler or PDFium. These libraries are fast and battle-tested, but they run as native binaries. You couldn't run them in a browser. So every PDF tool sent your files to a server where these libraries lived.
That was the only realistic option... until WebAssembly.
What WebAssembly actually does here
WebAssembly (WASM) is a binary instruction format that runs in the browser at near-native speed. The key insight for PDF tools: you can compile existing C/C++ libraries directly to WASM and run them client-side.
This means the same PDF processing libraries that used to require a server can now execute inside the user's browser tab. No network request. No upload. The file never leaves the device.
Here's a simplified mental model of what happens when a user merges two PDFs on Aservus:
User selects files
↓
Files loaded into browser memory (File API)
↓
WASM module processes files locally
↓
Output written to browser memory
↓
User downloads result
↓
Memory cleared
At no point does any file data travel over the network. You can verify this yourself — open DevTools, go to the Network tab, and process a file. You'll see zero outgoing requests carrying your document.
What we built
Aservus currently has 23 tools running this way: merge, split, compress, protect with password, remove password, add watermark, rotate, reorder pages, PDF to image, image to PDF, and more.
All of these run locally. The Vanilla JS frontend handles the UI, file selection, and download. The WASM module handles the actual PDF operations.
Performance is better than you'd expect. Merging 10 typical PDFs takes 2-4 seconds on a modern laptop. Compressing a 20MB file runs in under 10 seconds. The bottleneck is usually memory allocation rather than computation.
The one thing we couldn't do locally yet
PDF to Word conversion. This requires machine learning models to recognize text layout, handle complex formatting, and reconstruct document structure. Those models are currently too large to ship as a WASM bundle that loads in reasonable time.
For this specific tool, we use server-side processing — but we're transparent about it in the UI, and files are deleted immediately after conversion. We label every tool clearly: "processes locally" or "processed on secure server."
Honesty about the hybrid model turned out to matter a lot to users. More on that below.
What surprised us
"Never uploads" is a trust signal, not a feature claim. When we changed our homepage headline from a feature list to "Most PDF tools upload your files to a server. Aservus doesn't." — time-on-page improved noticeably. Users stopped and read. The claim is verifiable (DevTools, Network tab, zero requests) and that verifiability is what makes it land differently than a typical marketing line.
Memory management is the real constraint. WASM runs in the browser's memory sandbox. For very large files (100MB+), you can run into browser memory limits. We handle this with streaming where possible, but it's an active area of work. Server-side tools don't have this problem.
PWA matters more than we expected. Because the processing is local, Aservus works offline for all the WASM-based tools once the app is loaded. Users who install it as a PWA get a genuinely offline PDF toolkit. That's a meaningful use case we didn't fully anticipate at launch.
The privacy model in plain English
For the tools that matter most — the ones people use with sensitive documents — your files stay on your device. Period. You can verify it with DevTools. For the one tool that can't run locally yet (PDF to Word), we tell you upfront and delete immediately.
We think this is how privacy-first software should work: not just a policy you have to trust, but a technical architecture you can verify.
Try it
Aservus — 23 free PDF tools, no sign-up, no watermarks, no usage limits.
If you have questions about the WebAssembly implementation or want to discuss the technical architecture, drop them in the comments. Happy to go deep on any part of this.
Top comments (0)