I Built 50 PDF Tools That Never Upload Your Files — Here's How They Run Entirely in the Browser

Think about the last time you used a "free PDF tools" site.

You needed to merge two PDFs, compress a scan, or sign a contract. So you dragged your file into the browser and watched a progress bar while a copy of that document — a contract, a bank statement, a scan of your ID — was uploaded to a server owned by people you have never met.

Does the site delete it afterwards? Maybe. There is no way for you to verify it. The privacy policy says "we take your privacy seriously," which is easy to write and impossible to audit.

Here's the part that bothered me enough to start a project: the upload was never actually necessary. It's a habit the industry formed when browsers were weak. Modern browsers ship with WebAssembly, Web Workers, and more than enough CPU power to do this work locally. A PDF doesn't need to travel to a datacenter to be merged, split, encrypted, or OCR'd — it can be processed in the same tab where it already lives.

So I built OnyxPDF: 50 PDF and image tools that run entirely in the browser.

What was built

OnyxPDF is a set of 50 tools — 32 PDF tools and 18 image tools — that run 100% client-side. No server processing, no uploads, no account, and no cost.

The simple tools are the ones you'd expect: rotate, reorder pages, extract pages, resize and convert images. The interesting engineering was in the hard ones:

• Merge, split, compress, and convert PDFs without the file ever leaving the tab
• OCR in 7 languages, turning scanned pages into searchable, selectable text
• True redaction — actually removing the underlying text and image data, not just drawing a black rectangle over it that anyone can peel back
• Signing documents directly in the browser
• Real AES-256 encryption, the strongest encryption the PDF format supports, applied locally
• AI background removal for images, using a segmentation model that runs on-device instead of a remote API

How it works

PDF parsing and manipulation in a Web Worker

PDFs are parsed, manipulated, and rebuilt entirely with JavaScript and WebAssembly. All of that heavy work runs inside a Web Worker, so the main thread stays responsive and the UI never freezes — progress bars keep animating even while a long document is being rebuilt page by page.

The shape of it looks like this:

// Main thread: hand the bytes off, stay responsive
const worker = new Worker("pdf-worker.js");
worker.postMessage({ type: "merge", files: [bufA, bufB] });
worker.onmessage = (e) => saveResult(e.data.output);

// pdf-worker.js: the heavy lifting happens off the UI thread
self.onmessage = async (e) => {
  const output = await mergeDocuments(e.data.files);
  self.postMessage({ output });
};

OCR via a WebAssembly build of Tesseract

OCR is the feature people most assume "needs" a server. It doesn't. Tesseract, the open-source OCR engine, has a build that compiles to WebAssembly, so the same engine that powers server-side OCR pipelines can run inside a browser tab. OnyxPDF uses it to recognize text in 7 languages, entirely on your machine.

Encryption, implemented client-side

AES-256 isn't something you bolt onto a PDF afterwards — it's part of the PDF format itself, and it's the strongest variant the spec defines. Because the format supports it natively, the encryption can be applied completely on the client. Your password never gets transmitted, and neither does the document. Which is good, because "upload your confidential file so we can encrypt it for you" is a sentence that should make everyone pause.

Background removal with an on-device model

Most background-removal tools are a thin frontend over someone else's hosted API: your photo gets uploaded, processed remotely, and billed by the call. OnyxPDF instead ships a segmentation model that runs on-device, in the browser. Your photos stay on your machine, and there is no per-image API cost hiding anywhere.

The gotcha: large files and browser memory limits

The hardest problem wasn't any single tool. It was memory.

A server can throw RAM at a problem. A browser tab can't — it lives under strict heap limits, and those limits are tighter on mobile devices. A PDF that looks harmless on disk can balloon in memory once you start decoding it. Render a long scan at high resolution and suddenly you're holding hundreds of megabytes of raw page bitmaps at once.

What made it workable:

• Chunking — process page by page instead of loading the whole decoded document into memory: handle a page, release it, move on
• Workers everywhere it matters — long tasks and their garbage stay off the main thread
• Releasing decoded pages aggressively as soon as a page is finished, instead of letting bitmaps accumulate
• Streaming results out where possible, rather than building one giant in-memory structure

None of this is exotic. It's just the discipline of treating the browser as the resource-constrained environment it actually is — the same discipline server-side tools never had to learn, because the server could always be given more RAM.

The proof anyone can run

You don't have to take any of this on faith, because the architecture makes it verifiable in about thirty seconds:

1. Open OnyxPDF and let the page load.
2. Switch your device to airplane mode.
3. Pick any tool and process a file.

Everything still works — because there is no server to disconnect from.

Prefer a second test? Open your browser's Network tab while converting a file and watch the requests. Beyond loading the page itself, nothing uploads your document. Zero file uploads, because there is nowhere for them to go.

Try it

OnyxPDF is free, needs no account, and lives here:

👉 https://onyxailabs.github.io/onyxpdf/

It's built by Onyx AI Labs, and it's actively maintained. Feedback is genuinely wanted — if there's a tool you wish existed, or you hit a bug, I want to hear about it.

I'll close with the question that started this whole project:

Which PDF tool do you still have to upload files to a random site for?