Every day, millions of people drag sensitive documents into online PDF tools and hit upload. Contracts, medical records, tax returns, legal filings — all traveling across the internet to servers they don't control, processed by software they can't inspect, stored under retention policies they haven't read.
We thought there had to be a better approach. So our team built ModernPDF — a suite of 28 PDF tools that run entirely in the browser. No upload. No server processing. Files never leave the user's device.
Here's what we learned building it.
The Architecture in One Sentence
The browser is the server.
Every operation — merge, split, compress, convert, redact, OCR, translate — runs client-side using WebAssembly and modern browser APIs. The backend serves static assets and handles authentication. That's it. User files exist only in browser memory and are gone when the tab closes.
Why WebAssembly Changes Everything
A few years ago, this wasn't practical. JavaScript alone couldn't handle the computational demands of real PDF manipulation — compression, rasterization, font subsetting, image resampling. You'd hit memory limits, freeze the UI, or produce unusable output.
WebAssembly changed the equation. Libraries written in C++ and Rust — the same ones that power desktop PDF software — now compile to WASM and run at near-native speed inside a browser sandbox. The performance gap between "upload to server, process, download" and "process locally" has effectively collapsed for most common operations.
These are on a mid-range laptop. A modern phone handles the same operations in roughly double the time.
The Hard Parts Nobody Talks About
Getting a basic demo working with pdf-lib takes an afternoon. Building production-grade tools that handle real-world PDFs reliably takes months. Here's where the engineering challenges actually live.
Memory Management Is Your Problem Now
When a server processes a PDF, it has 16–64GB of RAM and an OS that manages memory efficiently. When a browser tab processes that same PDF, it gets maybe 1–2GB before Chrome kills it.
A 50MB PDF can balloon to 200–300MB in memory during processing. Multiply that by the intermediate buffers needed for compression or conversion, and you're pushing browser limits fast.
Aggressive cleanup and chunked processing. Process pages in batches rather than loading everything at once. Release buffers immediately after use. For conversion operations, stream pages through a pipeline rather than holding the full result set in memory.
This is the unglamorous work that separates "works on the demo" from "works on the 200-page scanned document your user's accountant just emailed them."
Not Every PDF Is a Good PDF
The PDF specification is over 1,000 pages long and has been extended dozens of times since 1993. In theory, every PDF follows the spec. In practice, PDFs generated by different software interpret the spec creatively.
Linearized PDFs, encrypted PDFs, PDFs with embedded fonts referencing missing glyphs, PDFs with corrupt cross-reference tables that Adobe Reader silently repairs but every library chokes on. Scanned documents that are giant images wrapped in a PDF container. Files that claim to be version 1.4 but use features from 2.0.
Our codebase for handling "broken" PDFs is larger than the codebase for handling correct ones.
Offline Is Harder Than It Sounds
"Works offline" sounds straightforward — cache the assets and you're done. The details say otherwise.
WASM modules can be large. The first load fetches everything; subsequent loads hit the browser cache. But browsers evict cache under storage pressure, especially on mobile. That requires a service worker strategy that's aggressive about caching WASM binaries without bloating the device.
Then there's the UX question: if a user opens a tool while online and loses connectivity mid-operation, does it still work? For pure client-side tools, yes. For tools that call an API (like our AI translation), you need graceful degradation — queue the request, surface an honest error, or offer an offline fallback.
AI Features Without Uploading Files
This was the most interesting architectural challenge. ModernPDF includes AI-powered translation (full document translation preserving layout) and AI-powered redaction (auto-detecting names, addresses, SSNs, and other PII).
The naive approach — send the file to an AI API — defeats the entire privacy premise. Our approach extracts text client-side, sends only the text content to our API proxy (with rate limiting and no file storage), and reassembles the result back into the PDF in the browser.
The file itself — the binary PDF with its images, fonts, signatures, and metadata — never leaves the device. The AI processes extracted text only. The actual pixel-level redaction (replacing detected content with permanent black boxes in the PDF structure) happens entirely client-side.
Is this a perfect privacy guarantee? No — text content still hits a server for AI processing, and we're transparent about that. But it's categorically different from uploading entire files to a third party. And for the non-AI tools, nothing leaves the browser at all.
Lessons From Production
Fewer tools, more distribution. We built 28 tools across 9 languages before investing seriously in distribution. That's backwards. Five polished tools with strong discoverability would have outperformed 28 tools that nobody could find. Engineering teams tend to over-index on building and under-index on reaching users.
Content is infrastructure, not an afterthought. The best product doesn't matter if search engines don't know it exists. We spent months on engineering and weeks on content. In hindsight, those should have been closer to balanced.
Mobile-first memory management. Desktop browsers are forgiving. Mobile Safari with 3GB of total system RAM processing a 100-page PDF is not. The memory patterns we described above were learned through production incidents on mobile devices, and retrofitting them was significantly more painful than building them in from the start.
By the Numbers
The product is live at modernpdf.app. Our architecture page covers the technical details in more depth.
What We're Exploring Next
- WebGPU for PDF rendering — could significantly accelerate conversion operations. Browser support is still uneven, but the potential for image-heavy PDFs is substantial.
- Larger file handling — the practical limit today is a browser memory constraint, not a design choice. Streaming processing with SharedArrayBuffer could push this higher.
- Client-side OCR accuracy — current WASM-based OCR handles standard documents well but struggles with complex layouts. The gap between client-side and server-side OCR is real, and we're watching the ecosystem closely.
The shift from "upload everything to the cloud" to "process everything locally" is one of the more compelling architectural trends in web development. We think it's still early.