I Built a PDF Toolbox That Never Uploads Your Files — Here's How

Source: Dev.to

Every “free online PDF tool” uploads your files to a server. I built one that doesn’t — and here’s the technical breakdown. 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 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 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 can create and modify PDFs entirely in memory. It supports merging, splitting, compressing, password protection, page rotation, and font embedding — all without native dependencies. 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. 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 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 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. 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?