DEV Community: Muhammad Zain Shabbir

How WebAssembly makes it possible to process PDFs entirely in your browser

Muhammad Zain Shabbir — Thu, 02 Apr 2026 11:38:45 +0000

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.

Why I chose Vanilla JavaScript over React for a production SaaS tool — and would do it again

Muhammad Zain Shabbir — Tue, 24 Mar 2026 02:05:49 +0000

When I started building Aservus — a free PDF toolkit at aservus.com — the first decision I made was to use zero JavaScript frameworks.
No React. No Vue. No Svelte. Pure HTML, CSS, and Vanilla JavaScript.
Every developer I mentioned this to had the same reaction: "Why would you do that for a production tool?"
Here is my honest answer.
The use case made frameworks unnecessary
Aservus is a collection of single-purpose tool pages. Each page does one thing — merge PDFs, compress a PDF, convert PDF to Word. There is no complex shared state across components. There is no real-time data syncing. There is no authentication flow with dozens of conditional UI states.
The use case that frameworks solve brilliantly — complex, stateful, interactive applications — was not my use case. My use case was: user arrives, user selects file, tool processes file, user downloads result.
A framework would have added complexity without solving any problem I actually had.
Performance was non-negotiable
PDF tools are used by people in a hurry. Someone needs to compress a file before a job application deadline. Someone needs to merge documents before a meeting starts. They are not browsing — they are trying to get something done in under 60 seconds.
Every millisecond of load time is a conversion killer.
Vanilla JS with no build step, no hydration, no bundle parsing means tool pages load near-instantly. The first contentful paint is fast because there is nothing heavy to parse. The user sees the upload interface immediately.
A React bundle — even optimised — adds overhead that I could not justify for pages where speed is the core product feature.
WebAssembly integration is simpler without a framework
Most of the PDF processing on Aservus runs locally in the browser using WebAssembly compiled libraries. Loading and initialising a WASM module, managing its memory, and handling the async processing pipeline is already complex enough.
Adding a framework layer on top would have meant managing WASM lifecycle inside component lifecycle hooks — which creates more surface area for bugs without any benefit.
With vanilla JS I have direct control over exactly when modules load, how memory is managed, and when the UI updates. That control matters when you are processing binary file data in the browser.
What I would use a framework for
I am not anti-framework. If I were building the analytics dashboard for Aservus — something with real-time charts, filterable tables, multiple interconnected views — I would reach for React or Vue without hesitation.
Frameworks are the right tool for stateful, complex, component-heavy interfaces. They are the wrong tool for fast, focused, single-purpose tool pages.
The actual outcome
The site is a PWA with a service worker. Tools work offline. Pages load fast. The codebase is simple enough that I can read and understand every part of it without a build system or mental model overhead.
If you are building a tool-focused product where performance directly affects user satisfaction — I would seriously reconsider the default assumption that you need a framework.
What are your thoughts? Has anyone else made a similar call on a production project?

How I Built a Free PDF Tool That Processes Files Locally in the Browser

Muhammad Zain Shabbir — Fri, 20 Mar 2026 19:43:18 +0000

If you have ever used iLovePDF, Smallpdf, or Sejda to merge or compress a PDF, your file was uploaded to a remote server you know nothing about. Most people do not realise this is happening. The tools work so smoothly that the upload is invisible.
I realised this one day when I uploaded a contract to compress it before sending. It worked fine. Then I thought about what had actually happened — I had just sent a sensitive legal document to a server I had never heard of, in a location I did not know, to be processed by software I could not inspect.
That bothered me enough to build something different.
What I Built
I built Aservus — a free online toolkit available at https://aservus.com with 23 tools for working with PDF files and documents.
The core idea: process as much as possible locally in the browser so files never leave the user's device.
The Technical Architecture
Aservus uses a privacy-first hybrid model. Here is how it breaks down honestly:
Local processing (WebAssembly in the browser):
Most PDF editing operations run entirely client-side using WebAssembly compiled libraries. This includes merge, split, compress, protect, watermark, rotate, and repair. When a user merges PDFs on Aservus, the processing happens on their own machine using their own CPU. The file never touches a server.
Server processing (secure, with immediate deletion):
Complex format conversions like PDF to Word, Word to PDF, PDF to Excel, and HTML to PDF require server-side processing. The technical reason is that accurate layout analysis and format reconstruction at this level of fidelity is not yet feasible to run entirely client-side. For these operations, files are uploaded to a secure server, processed, and deleted immediately after the user downloads the result.
I want to be transparent about this distinction because I think users deserve to know exactly what happens to their files. Hiding server processing behind vague privacy policies is exactly the problem I was trying to solve.
The Tech Stack
The frontend is pure HTML, CSS, and vanilla JavaScript. No frameworks. The backend is Node.js and Express with LibreOffice, Ghostscript, and wkhtmltopdf for server-side processing. Most client-side PDF operations use PDF-lib and pdf.js compiled to WebAssembly. The site is a PWA with a service worker and is hosted on shared hosting.
I deliberately avoided heavy frameworks because I wanted the tool pages to load instantly. When someone needs to merge a PDF they want to do it in 10 seconds, not wait for a React bundle to hydrate.
What Aservus Includes
PDF tools: merge, split, compress, protect, sign, watermark, rotate, repair
Converter tools: PDF to Word, Word to PDF, PDF to Excel, Excel to PDF, Image to PDF, PDF to JPG, HTML to PDF, PDF to HTML
Utility tools: AI Paraphraser, QR Code Generator, Word Counter, Email Extractor, Age Calculator, YouTube Analytics Tracker
Everything is free. No account required. No watermarks. No daily limits.
What I Learned Building This
Privacy is a design decision, not a feature. Every technical choice either respects user privacy or compromises it. Choosing to use WebAssembly for PDF editing instead of server processing was a privacy decision before it was a technical one.
Transparency builds more trust than perfection. I could have claimed everything runs locally and most users would never know the difference. Instead I built a clear indication on each tool page showing whether it processes locally or requires a server. Users respond well to honesty.
Vanilla JS is underrated. The site is fast, the tools load instantly, and there is zero dependency hell. For a tool-focused site where performance directly affects user experience, avoiding frameworks was the right call.
Try It
Aservus is live at https://aservus.com and completely free. I would genuinely love feedback from developers — especially on the WebAssembly implementation, the hybrid model approach, and what tools are missing.
What would make you switch from whatever PDF tool you are currently using?