Suprabhat Mondal

Posted on Oct 3 AI-assisted

Why We Moved PDF Processing Entirely to the Browser with WebAssembly (and 0 Server Uploads)

#webassembly #javascript #webdev #privacy

If you’ve ever built a web application that handles file conversions or document processing, your default backend architecture probably looks something like this:

User uploads a file via multipart/form-data to an S3 bucket or API endpoint.
An asynchronous worker queue (Node.js, Python, or Go) processes the file using pdftk, Ghostscript, or ImageMagick.
The processed file is written back to storage.
A temporary signed URL is returned to the client to download the result.

While this pattern works, it introduces three expensive bottlenecks: high server bandwidth costs, cloud storage lifecycle management, and—most importantly—privacy risks. Users are forced to trust your backend with sensitive NDAs, medical records, or personal tax returns.

When building FixMyPDFs.cc, we decided to challenge this architecture by asking a simple question: Can we handle complex file manipulation and PDF editing entirely client-side?

Architecture TL;DR: By compiling C/Rust PDF execution engines into WebAssembly (Wasm) and offloading compute tasks to Web Workers, we eliminated backend servers, eliminated compute costs, and achieved true zero-upload privacy.

Here is how we built a zero-server document processing engine using WebAssembly (Wasm) and modern JavaScript APIs.

1. Shifting Heavy Lifting to WebAssembly (Wasm)

Historically, browser-based document manipulation was limited to basic canvas rendering or light text injection. Complex tasks like merging multi-gigabyte PDFs, running lossless compression algorithms, or rendering PDF pages into vector paths required C/C++ libraries.

Thanks to WebAssembly, compiled C/C++ and Rust libraries can now run in the browser tab at near-native speeds.

How Client-Side Execution Works:

When a user opens FixMyPDFs, the browser fetches cached WebAssembly binaries (compiled from open-source C/Rust PDF engines).

// Example: Loading a WebAssembly module client-side
import { loadWasmModule } from './pdf-engine.wasm';

async function processPdfLocally(fileArrayBuffer) {
  const wasmInstance = await loadWasmModule();

  // Allocate memory inside WebAssembly module
  const pointer = wasmInstance.exports.allocateMemory(fileArrayBuffer.byteLength);

  // Pass document array buffer directly in RAM
  const resultPointer = wasmInstance.exports.compressPdf(pointer, fileArrayBuffer.byteLength);

  // Extract processed binary data
  return wasmInstance.exports.readMemory(resultPointer);
}

Because execution happens in the user’s local browser RAM:

Upload latency is 0ms: There is no network transfer delay.
Server overhead is $0: Static assets are served via CDN; CPU cycles belong to the client device.
Privacy is guaranteed: Open your browser's DevTools -> Network tab. When you process a document on FixMyPDFs.cc, zero payload bytes leave your device.

2. Leveraging Web Workers for Non-Blocking UI

Heavy computational tasks—like parsing multi-page document trees or calculating image compression vectors—can quickly block the main browser thread, causing UI jank or frozen frames.

To ensure a smooth 60fps user interface, all heavy computational routines are offloaded to Web Workers.

Data Flow Architecture:

Main UI Thread: Sends the raw ArrayBuffer payload to the Web Worker thread via postMessage.
Web Worker Thread: Loads and executes the compiled WebAssembly binary isolated from the UI thread.
Return Event: Transfers the updated ArrayBuffer back to the main thread as a downloadable Blob.

By transferring ArrayBuffer objects by reference (using Transferable objects), data isn't cloned across memory threads, preserving system memory even when handling 100MB+ files.

3. Privacy-First UX as a Developer Competitive Advantage

Legacy cloud-based tools rely on server infrastructure, forcing them to institute:

File size caps on free tiers.
Strict daily rate limits (e.g., 2 tasks per day).
Monthly subscriptions to cover API compute costs.

By moving processing to the edge (specifically, the user’s own browser window), platforms like FixMyPDFs.cc eliminate server compute costs entirely. This allows us to offer unlimited usage, zero file size caps, and instant offline execution without hidden paywalls.

Key Engineering Trade-Offs to Consider

Client-side execution is powerful, but it isn't a silver bullet. If you're considering building a client-side document processing tool, keep these limitations in mind:

Hardware Constraints: Low-end mobile devices with 2GB RAM may struggle with massive 500-page file conversions compared to high-core cloud servers.
Initial Asset Load: WebAssembly binaries add a few megabytes to the initial page bundle (though this can be mitigated with Service Workers and aggressive caching).
Complex OCR Models: High-accuracy Optical Character Recognition (OCR) or deep AI model inference still occasionally requires server GPU capabilities depending on the model size.

Conclusion

The browser is no longer just a document viewer—it’s an operating system in its own right. Shifting heavy file conversion, compression, and editing away from cloud servers to local WebAssembly engines is better for data privacy, cheaper for developers, and faster for users.

Inspect Network Traffic on FixMyPDFs.cc

What are your thoughts on WebAssembly for client-side file tools? Have you experimented with Wasm in production? Let's discuss in the comments below!

DEV Community