Building a private PDF toolkit: Moving document processing entirely to the client

We have all been there. You need to quickly compress a sensitive contract, merge a few invoices, or sign an NDA. But radiography on page one of Google shows that literally every tool forces you to upload your private files to their remote server. You just have to cross your fingers and hope they actually delete your data afterward.

As a student building stuff, shipping a massive 100MB PDF across the network just to merge two pages felt super inefficient and honestly kind of sketchy.

I wanted to fix this, so I built PDFOmni. It is a browser-based PDF toolkit where all the heavy lifting happens locally on your device. No backend storage, no server queues, and zero knowledge of your documents.

Shifting the Architecture

Most traditional document tools rely on server-side processing using heavy backend libraries. The workflow is always the same: you upload the file, the server processes it, and then you download it.

By shifting the computation entirely to the client side, the architecture changes completely. The browser loads the file directly into its own memory, processes it locally using scripts, and saves it straight back to your disk.

Tackling Browser Memory Limits

The biggest hurdle in building a purely client side tool is memory management. Browsers love to kill tabs that spike memory usage, so you have to be really careful.

When building the local PDF compressor, I had to ensure the browser could handle heavy, image-dense scanned documents without crashing. By optimizing the local scripts, the site can comfortably handle files up to 500MB right in the browser. You just choose your target size, and the browser handles the work of stripping out redundant data and downsampling images locally.

The same logic applies to the PDF merging tool. The trick was keeping the interface snappy while holding multiple documents in the browser's memory before combining their buffers into a single downloadable blob.

How the AI Copilot Handles Privacy (Hybrid RAG)

I also wanted to add an AI assistant to help summarize or query documents, but I had to handle it carefully to protect privacy.

To keep things secure, the entire RAG (Retrieval-Augmented Generation) pipeline runs locally on your device. The app extracts the text and retrieves the relevant parts of the PDF right inside your browser.

When you want to chat with the document, the app asks you to enter your own OpenRouter API key. Only the specific text snippets needed for your question are sent server side to the LLM to get the response. Your actual PDF file never touches a backend server, meaning you get powerful AI models without giving up your data.

Why do it this way?

Dropping the typical server requirement comes with some huge perks:

1. 
   Speed: It is as fast as your local machine. You do not have to wait for network uploads or server queues.


2. 
   Cost: Without server instances crunching PDFs 24/7, I do not have to gate the tools behind a paywall or strict rate limits.


3. 
   Privacy: Your original files never leave your device.

I am currently trying to optimize all tools on the website even further. If you work with heavy PDFs or have experience tweaking client side memory limits, I would love to get your feedback on how it handles your files. I would also love to know what other features you'd like me to add.