I Built a PDF Suite That Never

The short answer

A PDF suite can run entirely in your browser tab because three pieces of open-source engineering finally lined up: Mozilla's PDF.js renders and parses documents on HTML5 Canvas, pure-JavaScript pdf-lib creates, merges, and fills forms with zero native dependencies, and WebAssembly ports of heavyweight C/C++ libraries (MuPDF, QPDF, Ghostscript) now handle compression, decryption, and OCR without shelling out to a processing server. Our pdf-merge and pdf-compress tools on VritantaNextGen are built on this stack: your file is read, transformed, and re-downloaded inside the tab. It never uploads.

That's the whole trick. No server-side queue, no temp-file cleanup job, no "we delete your files after 24 hours" privacy policy to trust — because there's no server leg for your document to travel over in the first place. Here's how the pieces actually fit together, and why this only became credible in the last few years.

Why parsing and rendering moved to the browser first

Mozilla's PDF.js is the default engine for reading PDFs without a plugin — it's been shipping inside Firefox for years and is now a general-purpose web-standards PDF platform. The npm package pdfjs-dist sits at version 6.2.108, published July 28, 2026, and pulls roughly 17.2 million weekly downloads with about 53.6k GitHub stars, according to package metrics. That download volume matters: it means PDF.js isn't a niche experiment, it's infrastructure that thousands of production apps already depend on to decode PDF structure and paint pages to a <canvas> element client-side.

It's telling that even server-oriented projects lean on it. Stirling-PDF's 2.0 development docs explicitly use PDF.js for client-side rendering, layering it with pdf-lib and IndexedDB for local state — proof that rendering-in-the-browser is now the default assumption even for a tool that still processes most operations on its own infrastructure.

The create/merge/edit layer: pdf-lib, and its unmaintained problem

Rendering a PDF is one thing; building or restructuring one is another. That's pdf-lib's job — a pure-JavaScript API for creating, modifying, splitting, merging, and filling forms that runs in browsers, Node, Deno, and React Native with no native dependencies, per its own documentation. It's what powers merge-style operations like the one behind our PDF merge tool: combining multiple documents into one, entirely in memory, in the tab.

The catch, and it's a real one: pdf-lib's canonical npm package is still at version 1.17.1, last published roughly five years ago, and Snyk flags its maintenance status as Inactive — despite still pulling an estimated 8.6–10.9 million weekly downloads. Hacker News threads describe the Hopding/pdf-lib repo as unmaintained for four-plus years. The ecosystem's response has been to fork it: @cantoo/pdf-lib is an actively maintained fork now on the 2.7.x line in 2026. Documenso, writing in January 2026, praised pdf-lib's API design but flagged edge-case failures at volume — serious enough that they built a successor library, LibPDF, rather than keep patching around it. If you're evaluating client-side PDF tooling for anything beyond hobby use, this is the fact to know: the most-downloaded library in the category is frozen, and the community has already voted with forks.

The heavy-lifting layer: WebAssembly

PDF.js and pdf-lib cover rendering and structural edits, but compression, decryption, and OCR are computationally heavier — historically the reason PDF tools ran on a server at all. WebAssembly changed that math. Artifex ships MuPDF.js, a WASM build of MuPDF distributed on npm for client-side PDF work on the web. QPDF has WASM demos running optimize, compress, and decrypt operations directly in-browser. This isn't a new idea — Go's pdfcpu was compiled to WASM back in 2019, and its author's argument then is the same one driving adoption now: uploading a file to a server for processing adds latency and creates a confidentiality problem you don't need if the computation can happen locally.

The pattern shows up again in how BentoPDF is built: it loads PyMuPDF, Ghostscript, and CoherentPDF as WASM modules, typically pulled from a CDN like jsDelivr with a documented local fallback for air-gapped use. Office-to-PDF conversion is the hardest case — it needs a full LibreOffice WASM build, which requires SharedArrayBuffer and the COOP/COEP security headers to work at all — but even that runs client-side now. Compression, the operation behind our PDF compress tool, sits squarely in this WASM-powered category: it's exactly the kind of CPU-heavy transform that used to justify a server round-trip and no longer does.

The market proof: two very different "self-hosted" stories

Two open-source projects make the contrast concrete. BentoPDF, on GitHub as alam00000/bentopdf, has around 14.5k stars and is dual-licensed — AGPL-3.0 for free use, or a $79 lifetime commercial license. Its README states plainly that all processing happens in the browser, there is no server-side processing, and self-hosting is just serving static files (or a Docker image that only serves assets, never processes documents). It ships 50+ tools spanning merge, split, edit, redact, sign, encrypt, OCR, and Office conversion — all client-side.

Stirling-PDF is the bigger project by far — about 88.5k GitHub stars — and describes itself as offering desktop, browser UI, and self-hosted server modes "without sending documents to external services." But read that phrase carefully: it means your infrastructure, not zero server. Maintainer discussion in GitHub issue #174 confirms many operations run server-side, using memory or temp files, while only some tools (multi-tool actions, rotate, sign) are client-side; server-processed files are deleted after the request completes. That's a legitimate privacy model — but it's a different one from BentoPDF's, and a different one from what we've built. Deleted-after-processing still means the file was transmitted and briefly resided somewhere outside your device.

Practitioners on Hacker News and Reddit have converged on a specific trust bar for this category: "never leaves the device" as a claim, backed by open source code and verifiable in the browser's own DevTools network tab — not a privacy-policy promise to take on faith.

That DevTools-verifiable bar is the right one, and it's worth applying to any tool making this claim, including ours: open the Network tab, run an operation, and confirm nothing goes out.

What this means for VritantaNextGen's tools

Our pdf-merge and pdf-compress tools sit in this same lineage — PDF.js-class rendering, pdf-lib-class structural operations, WASM-class compression — running fully client-side. We don't claim more than that. We're not claiming end-to-end encryption, we're not claiming a security audit, and we're not claiming feature parity with a 50-tool suite like BentoPDF. What we can say honestly, and what you can verify yourself in under a minute: your file is read into browser memory, transformed there, and handed back to you as a download. It never touches our servers, because for these specific operations, there's nothing for it to touch.

If you want to see the fuller tool catalog we're building out client-side, browse the tools directory, or check the blog for more breakdowns like this one as we add capabilities.

The takeaway

Client-side PDF processing isn't a marketing angle bolted onto a normal server-backed product — it's a specific, verifiable architecture made possible by three concrete open-source lineages: PDF.js for parsing and rendering, pdf-lib (or its maintained forks) for structural edits, and WASM ports of MuPDF/QPDF/Ghostscript for the operations that used to require a server. BentoPDF proves the model can scale to 50+ tools; Stirling-PDF's much larger star count proves the market wants self-hosted control even when it isn't zero-server. Knowing which category a tool falls into — and being able to check it yourself in DevTools — is the actual due diligence here, not the privacy copy on the landing page.