Have you ever stopped to think about where your files go when you use online PDF tools like Smallpdf, iLovePDF, or Adobe Online?
If you are signing a sensitive NDA, merging tax returns, or compressing medical records, uploading those documents to third-party cloud servers is a massive privacy risk. Most online tools require you to hand over your data, wait in processing queues, and eventually hit paywalls or daily file limits.
To solve this, I built PDFBlack: an open-source suite of 40+ PDF tools that processes 100% of your documents locally in your browser.
No files are ever uploaded. No servers touch your data. Here is how the client-side architecture works under the hood.
🏗️ The Problem with Traditional PDF SaaS
Traditional PDF tools follow a client-server paradigm:
- You select a 50MB PDF on your machine.
- The browser uploads the 50MB file over the network to their server.
- A backend worker processes the document.
- The server sends back a processed download link.
This architecture has three major drawbacks:
- Privacy & GDPR Compliance: Your confidential documents sit on someone else's infrastructure.
- Network Latency: Large PDFs take forever to upload and download on slower internet connections.
- Expensive Cloud Infrastructure: Running heavy PDF engines on server clusters costs a fortune, forcing tools to charge high subscription fees or impose strict task limits.
⚡ The Zero-Knowledge Client-Side Architecture
With modern web technologies—specifically WebAssembly (Wasm), Web Workers, and modern memory streaming—the browser is more than powerful enough to handle complex document manipulation directly on the client machine.
Here is the tech stack powering PDFBlack:
- Next.js (App Router) & TypeScript: High-performance frontend with server-side rendered SEO landing pages and fast client routing.
- Web Workers: Heavy PDF manipulation is completely decoupled from the UI thread to guarantee smooth 60 FPS interactions.
-
Client-side PDF Engines (
pdf-lib, WASM pipelines): Memory-efficient byte manipulation directly within browser memory.
🧵 Offloading Heavy Jobs to Web Workers
If you attempt to merge or compress a 200-page document on the main JavaScript thread, the user interface will freeze completely.
To solve this, all document processing runs inside dedicated Web Workers. Here is a simplified pattern of how our background worker handles heavy jobs:
typescript
// workers/pdf-process.worker.ts
import { PDFDocument } from 'pdf-lib';
self.onmessage = async (event: MessageEvent<{ fileBuffer: ArrayBuffer }>) => {
try {
const { fileBuffer } = event.data;
// Load document entirely in local memory
const pdfDoc = await PDFDocument.load(fileBuffer);
// Perform operations (e.g. page reordering, compression, optimization)
const modifiedBytes = await pdfDoc.save();
// Post back the modified buffer to the main thread
self.postMessage({ success: true, data: modifiedBytes });
} catch (error) {
self.postMessage({ success: false, error: (error as Error).message });
}
};
On the main thread, the app simply turns the resulting ArrayBuffer into an in-memory Blob and triggers a native download, instantly releasing the memory:
const blob = new Blob([data], { type: 'application/pdf' });
const downloadUrl = URL.createObjectURL(blob);
// Trigger download and revokeObjectURL immediately to prevent memory leaks
🛠️ The Core Suite Tools
By executing everything client-side, we were able to deliver features that usually cost $15/month completely free:
Merge PDF: Combine hundreds of pages in seconds with real-time drag-and-drop page reordering.
Compress PDF: Smart compression calibrated to common file limits (e.g., shrinking court filings to under 1MB or 2MB) without server queues.
Bates Legal Numbering & Page Foliation: Critical for legal teams and accounting professionals who cannot legally upload discovery documents to external servers.
Offline Capability: Once the page and workers are loaded, you can literally disconnect your Wi-Fi and continue processing documents uninterrupted.
🚀 Key Takeaways & What's Next
Building a 100% client-side application taught us that modern browsers are essentially micro-operating systems. By shifting compute to the client:
Server hosting costs drop to nearly zero (static edge delivery).
Users get instant speed without uploading massive files.
Privacy is mathematically guaranteed, not just promised in a privacy policy.
The project is live at pdf-black.com, and you can explore the codebase on our GitHub repository.
I’d love to hear your thoughts: what other developer or office workflows do you think should migrate completely from the cloud into client-side WebAssembly?
Top comments (0)