How WebAssembly became our privacy architecture (not just a performance trick)

Most WebAssembly articles discuss performance, but this article focuses on how WebAssembly's sandboxed execution model enhances privacy. Traditional PDF processing tools transfer files to remote servers, increasing the risk of exposing sensitive data like tax returns, medical records, or legal contracts. The goal was to make the upload process architecturally impossible, not just unlikely.

WebAssembly modules run inside the browser's sandboxed execution environment, preventing network connections. They can only communicate with the outside world through explicitly provided JavaScript host functions. This structural constraint ensures no network requests carrying file data can exist during processing. The in-browser pipeline involves reading the file locally, passing it to a Wasm module, creating an output Blob, triggering a local download, and cleaning up memory. The entire process occurs in browser memory, with no network requests involved.

The stack uses open-source WebAssembly libraries for PDF processing (pdf-lib), PDF parsing (pdfjs-dist), OCR (Tesseract.js), and HEIC decoding (heic2any). All processing occurs in the browser, avoiding server infrastructure and reducing the breach surface. Clients can verify the privacy claim by examining the Network tab in DevTools after processing a file. No requests containing file bytes as payload should appear.

While client-side Wasm processing has tradeoffs, such as large Wasm binaries, slower processing on low-powered devices, and limited browser memory, the benefits outweigh the drawbacks for occasional document processing. The architecture offers zero infrastructure costs for processing, offline capability, and eliminates server-side storage of file data, enhancing overall privacy.