How OmniPDF works

OmniPDF processes PDFs entirely in your browser. This page explains the architecture and why it matters.

The traditional approach

Most online PDF tools work like this:

1. You select a file on your device.
2. Your browser uploads the file to a server.
3. The server processes it (possibly in a queue, possibly on a machine you have no visibility into).
4. The server sends the result back.
5. Your browser saves it to disk.

This works, but it means a copy of your document leaves your device, travels over the network, and sits on someone else's server for some period of time. For contracts, medical records, tax returns, ID scans and internal reports, that is a real privacy cost.

The OmniPDF approach

OmniPDF reverses the model:

1. You select a file on your device.
2. Your browser reads the file from disk into memory. The file never leaves your device.
3. The JavaScript libraries loaded into the page process the file in your browser tab.
4. You save the result to disk.
5. When you close the tab, all in-memory data is discarded.

There is no server receiving the file. There is no upload step. There is no queue, no storage bucket, no retention policy to worry about.

The libraries behind every tool

OmniPDF uses several open-source libraries, all of them self-hosted (no runtime CDN dependency):

• pdf-lib (MIT) — creating and modifying PDFs, merging, splitting, forms, metadata, encryption.
• pdf.js (Apache-2.0) — rendering, text extraction, image extraction. Mozilla's library, the same one that powers Firefox's PDF viewer.
• Tesseract.js (Apache-2.0) — OCR. Runs in a WebAssembly worker.
• jsPDF (MIT) — PDF generation for text-based tools.
• JSZip (MIT / GPLv3) — ZIP packaging for multi-file outputs.
• SheetJS, Mammoth, PptxGenJS — Office format handling.
• html2canvas (MIT) — HTML rendering to canvas.
• SortableJS (MIT) — drag-and-drop reordering.

How processing works step by step

1. File selection

You select a file via the standard browser file picker or by dragging it into the drop zone. The file handle is provided to the page by the browser — the file is never re-uploaded anywhere.

2. Validation

The tool checks file type, file size and — for PDFs — that the file is not password-protected. If any check fails, the tool explains the specific error and does not proceed.

3. Memory assessment

For large files, the tool estimates the memory required and warns you if your device may not have enough. On low-memory phones, this warning is important: attempting to process a 100 MB PDF on a 2 GB phone may crash the browser tab.

4. Processing

The specific tool loads the libraries it needs and processes the file. Heavy operations (rendering, OCR, compression) run in Web Workers so the UI stays responsive. A progress bar shows you what is happening.

5. Output

The result is created as an in-memory Blob. You click Download to save it. The Blob URL is revoked after download so it does not persist in memory.

6. Cleanup

When you reset the tool or close the tab, any in-memory data is discarded. Object URLs are revoked. Worker threads are terminated.

Why Web Workers matter

JavaScript normally runs on the "main thread", the same thread that handles UI rendering. If you run heavy processing on the main thread, the entire page freezes — you cannot scroll, click or even see progress updates.

Web Workers run in a separate thread. Heavy processing goes to the worker, progress messages come back to the main thread, and the UI stays responsive. This is why a 30-second OCR job on a 5-page PDF does not lock your browser.

Why files are never uploaded

The architecture simply does not include an upload step. There is no code path in any tool that sends the file to a server. The JavaScript fetch and XMLHttpRequest APIs are used only to load library files from OmniPDF's own domain, never to send your data anywhere.

You can verify this yourself: open your browser's developer tools, go to the Network tab, and process any file with any tool. You will see requests for library files (all to omni-pdf.pages.dev) but no requests containing your file's contents.

Progress tracking

Every tool reports progress in the same way:

• Starting — the file is being read and the library is being prepared.
• Processing — the actual work is happening, page by page.
• Finishing — the output is being assembled.
• Complete — the file is ready to download.

If the process fails, you see a specific error message, not a generic "something went wrong".

What happens offline

OmniPDF is a Progressive Web App. The first time you visit a tool, its libraries and interface are cached in your browser. On subsequent visits — including visits with no internet connection — the tool loads from cache and works normally.

This is unusual and worth highlighting: after the first visit, you can use most OmniPDF tools on an airplane or in a network outage. Your files never leave your device either way.

What OmniPDF does not do

• It does not save files for you. Files stay in browser memory until you download them.
• It does not sync across devices. Each device processes its own files. There is no cloud sync because there is no cloud.
• It does not store history. If you close the tab, the file is gone. This is by design.
• It does not integrate with cloud storage. Adding Dropbox/Drive integration would mean connecting to a third-party API — a different privacy model that OmniPDF explicitly does not follow.

Comparing to server-based alternatives

	OmniPDF	Server-based
File leaves device	No	Yes
Processing speed	Faster for small files, slower for heavy OCR	Faster overall
Works offline	Yes (once cached)	No
Requires account	No	Often
Data breach risk	Only if your own device is compromised	Includes the server
Cost	Free	Free tier + paid upgrades