Every "free online PDF tool" uploads your files to a server. I built one that doesn't — and here's the technical breakdown.

The Privacy Problem

Try this: Google "compress pdf online free" and use the first 5 results. Each one uploads your PDF to their server, processes it, and gives you a download link. Your file sits on their server — anywhere from 1 hour to 14 days.

The privacy policies tell the story:

• Smallpdf: "We retain your files for 1 hour"
• iLovePDF: Files deleted after "a few hours"
• Adobe: "We may process your files to improve our services"

For contracts, tax forms, or medical records — this is a privacy disaster.

The Architecture: Client-Side PDF Processing

The core insight: you don't need a server to process PDFs. Everything can happen in the browser.

Tech stack:

• Next.js 16 — React framework, static generation
• pdf-lib — Pure JavaScript PDF manipulation library
• WebAssembly — Near-native performance for heavy operations
• Tailwind CSS — Responsive UI

The Processing Pipeline

User drops file → FileReader → ArrayBuffer
    → pdf-lib processes in memory  
    → new PDF blob → URL.createObjectURL()
    → download starts

No fetch(), no XMLHttpRequest, no FormData. The file never leaves the JavaScript heap.

pdf-lib: The Engine

pdf-lib can create and modify PDFs entirely in memory. It supports merging, splitting, compressing, password protection, page rotation, and font embedding — all without native dependencies.

Verify It Yourself

Open DevTools Network tab. Use any tool on the site. You'll see:

• Initial page load (HTML/CSS/JS)
• That's it.

No POST requests. No WebSocket uploads. The tools even work offline — disconnect your internet after page load and everything still functions.

What This Enables

When files never leave the browser:

• No file size limits — bounded only by device memory
• No account required — nothing to track, nothing to rate-limit
• Instant processing — no upload wait time
• True privacy — zero data retention, zero content analytics

The Trade-offs

• Very large PDFs (500MB+) can slow down the browser
• OCR requires Tesseract.js WebAssembly (heavy initial load, 2MB+)
• Some features (digital signatures, advanced form filling) are complex client-side

Why I Built This

Most PDF tools treat privacy as an afterthought — they add a "we delete your files after X hours" banner and call it a day. But privacy shouldn't be a footnote. It should be the architecture.

Building everything client-side was harder. But asking users to trust a server they can't verify isn't acceptable for sensitive documents.

Try It

The site is free, no signup required: pdftoolbox.tech

Source code: github.com/hwlsniper/pdftoolbox

Would love feedback from the Dev.to community. What other PDF operations would you want to see done entirely client-side?