PDF Toolkit — a fully client-side toolkit that never uploads your files

Why I built this

Every PDF tool online has one of three problems:

• Requires signup to use anything beyond “merge two files.”
• Hits an arbitrary limit — “free tier: 5 pages / 5 MB / 3 uses per day, upgrade to unlock.”
• Uploads your file to their server — usually to a shared bucket you don't control, sometimes indexed or logged, occasionally leaked.

For most people editing a signed contract or a bank statement, this is not what they want to be doing. Sensitive documents shouldn't leave the machine they're on. And yet the entire space is built around “upload, we'll process, download.”

I wanted a PDF toolkit that ran 100% in the browser — no server, no upload, no telemetry — with the full feature set (merge, split, compress, sign, fill forms, add text/images). Released under an open source license so nobody has to trust me.

Constraints

• Zero server-side processing. Files never leave the browser. Not “we delete after 1 hour” — never uploaded in the first place.
• Full feature parity with the big tools. Merge, split, reorder, compress, sign, fill, add text/images. Not a stripped-down version.
• No signup, no limits. Free forever. No dark patterns.
• MIT-licensed on GitHub. Anyone can fork, audit, self-host, or embed it.
• Embeddable. Should work as a standalone site or as a component in another web app.

What I shipped

• Merge, split, reorder pages — drag-and-drop UI to reorganize any PDF and save the result. Handles hundreds of pages without noticeable lag.
• Compress + optimize. Removes redundant metadata, downsamples embedded images intelligently. Typical 30-50% size reduction with no visible quality loss.
• Fill forms. Detects PDF form fields, lets you fill them in the browser, saves the completed PDF.
• Sign. Draw or upload a signature, drop it on any page, embed it as a proper PDF signature field.
• Add text or images to any page. Overlay editor with font and color controls.
• 100% client-side. Every operation runs in the browser via pdf-lib and WebAssembly. Server has zero role beyond serving the static bundle.
• MIT-licensed on GitHub. Full source, contributions welcome. Embeddable via <iframe> or as an npm package.

The hard parts

Compression without a server-side toolchain. Server-side PDF compression usually shells out to Ghostscript or qpdf. In the browser, you can't. I compiled a subset of these tools to WebAssembly and shipped them as a .wasm bundle loaded on demand. Compression runs in a worker thread so it doesn't lock the UI, and only loads when the user clicks “compress” (base bundle stays small).

Large-file performance. pdf-lib is written in JS. Processing a 200-page PDF in pure JS is not fast. I moved heavy operations (compression, image extraction, page manipulation for large docs) into Web Workers, and streamed operations where possible so a 500-page document doesn't crash the tab.

Making “no upload” believable. Users are used to PDF tools that quietly upload. Just claiming “we don't upload” isn't credible. I added a network activity indicator (visible “0 bytes uploaded” counter), an option to disable network access entirely once loaded (via service worker), and — since it's open source — a public GitHub repo people can inspect. The indicator is the small UX touch that made users actually believe it.

Signature that meets legal standards. A drawn signature that's just an image overlaid on a PDF is not a legally-valid signature. I built proper PDF signature-field embedding (via pdf-lib's signing APIs) so signed documents are recognizable by Adobe Reader and verifiable. Not a replacement for DocuSign in enterprise, but real signatures for personal use — not pretty overlays.

Result

Open source · zero telemetry, zero uploads. Used by developers, designers, and privacy-conscious users who don't want to hand their tax returns or contracts to a random SaaS.

MIT-licensed on GitHub. Embeddable in any site. People have forked it for internal enterprise deployments where their compliance teams love that everything stays client-side.

What I'd do differently

Should've shipped the “install as PWA” flow on day one. Many users want a “PDF app” they can open without opening a browser. It's a service worker + manifest change — I finally added it in month three, should've been week one.

Takeaway

Client-side processing is more capable than most developers assume. WebAssembly bridges the gap between “we need a server” and “we can do this in the browser,” but the ecosystem hasn't caught up to the possibilities yet. There's a real opening to build privacy-respecting tools that don't require trusting the operator. Users notice.