I built 35+ PDF tools that never upload your files (Rust + WebAssembly)

Most online PDF tools work the same way: you upload your file, a server processes it, and you download the result. That's fine for a flyer. It's less fine for a contract, a bank statement, or a medical report.

I wanted to know how far you can get with no server at all. The answer turned out to be: almost all the way. The result is InBrowserPDF, a set of 38 PDF tools where every file is processed entirely on your own device.

How it works

• Rust compiled to WebAssembly does the heavy work: parsing, merging, compressing, and encrypting.
• Web Workers run that code off the main thread, so the page stays buttery responsive while a multi-megabyte file is being crunched.
• The file never leaves the tab. You can check this yourself: open DevTools, go to the Network tab, and run any tool.

Under the hood, I leveraged a few key Rust libraries compiled to WASM. For low-level PDF object parsing, manipulation, and structural editing, I relied on lopdf, which gives fine-grained control over document dictionaries and streams without dragging in massive C++ dependencies. For page rendering and visual operations, I integrated lightweight bindings over pdfium, compiled down to WebAssembly to allow pixel-accurate rendering and thumbnail generation directly inside browser memory.

What was hard

Memory

WebAssembly memory management in the browser has strict boundaries. By default, WASM modules operate within a linear memory buffer that must be explicitly allocated and grown. When dealing with large PDF files, passing large ArrayBuffers back and forth between JavaScript and WASM can cause GC pauses and out-of-memory crashes on mobile devices or lower-RAM laptops.

That's why heavy operations like merging are capped at 100 MB total input size. If a file or combined set exceeds this threshold, the Web Worker catches the memory allocation failure gracefully and throws an explicit warning rather than letting the tab silently crash.

Office conversions

Converting Word (.docx), Excel (.xlsx), and PowerPoint (.pptx) documents entirely client-side is notoriously tricky because true layout fidelity requires a heavy document engine layout pass. To achieve this without a backend conversion server, I utilized browser-side WASM ports of document parsers combined with styled HTML/CSS layout templates rendered inside hidden DOM containers and printed via headless canvas/PDF generation APIs. Because of this DOM layout dependency, these conversions require modern desktop browser engines with hardware acceleration enabled to compute complex table structures and font metrics accurately.

OCR

For text extraction on scanned documents, I integrated Tesseract compiled to WebAssembly. While it works remarkably well offline, client-side OCR is computationally expensive. To keep memory footprints reasonable and processing times under a few seconds per page, the current WASM build is restricted to lightweight data packs optimized strictly for printed English text rather than heavy multilingual neural nets.

What I'd do differently

If I could rewrite one part of the architecture, I would have decoupled the larger WASM worker tasks earlier. Initially, I tried bundling too many disparate utility functions into a single monolithic Web Worker script, which bloated the initial worker initialization chunk and complicated error propagation. Splitting them into isolated, single-responsibility worker modules loaded on-demand via dynamic imports saved me days of debugging data-clone serialization bottlenecks.

What it can do today

• Merge, split, organize, extract, and remove pages
• Compress, repair, and OCR
• Convert Word, Excel, PowerPoint, JPG, and HTML to PDF, and back
• Edit, sign, fill forms, watermark, crop, and add page numbers
• Protect with AES-256, unlock, redact, compare, and remove metadata
• Convert PDF to Markdown and summarize

It's free and needs no account.

Known limits

• Merge handles up to 100 MB in total
• Compare handles up to 20 pages
• Batch handles up to 20 files
• OCR is printed English only

I'd like your feedback

If you try it, I'd like to know:

1. Did anything fail or slow down on a large or unusual file?
2. How did the Office conversions handle your real documents?
3. What would you want next?

Try it at inbrowserpdf.app, and tell me what breaks.