How the no-upload editing works

“Your files never leave your device” is a strong claim, and on most sites that make it, you’re taking their word. This page explains why, here, it isn’t a policy — it’s how the software is built — and how to check it yourself in under a minute.

The architecture, in plain terms

A PDF is a structured file, and restructuring files is ordinary computation — the kind your laptop or phone does constantly. When you open a tool page, your browser downloads the page and the editing engine itself, as JavaScript. When you drop a PDF onto the page, the file is read into your tab’s memory. Merging, splitting, rotating, stamping, flattening, compressing — all of it happens in that memory. The “Download” button hands you bytes assembled on your own machine.

There is no server-side half. The site is static files on a CDN — the same technology as a plain blog. It has no upload endpoint, no processing queue, no storage bucket. We could not read your documents if we wanted to, which is the only kind of privacy promise that doesn’t require trust.

Verify it — three ways, strongest last

1. Watch the network. Open DevTools (F12) → Network tab, then run any tool on a real file. You’ll see the page load its scripts and fonts — GET requests — and then nothing outbound while your document is processed. No POST, no PUT, no upload.
2. Cut the connection. Load a tool page, switch on airplane mode, then drop a file and run the tool. It works. Software that uploads your file cannot do this.
3. Check the receipts. The site ships a strict Content-Security-Policy header — readable in the Network tab’s response headers — that forbids the page from talking to any host except itself and the cookieless analytics beacon disclosed in the privacy policy. Even a bug couldn’t quietly send your documents anywhere: the browser itself would block the request.

What the engine actually is

The tools are built on pdf-lib, an open-source PDF manipulation library, with Mozilla’s pdf.js (the engine inside Firefox’s PDF viewer) drawing the page thumbnails. Both run entirely in the browser. Operations copy or edit PDF structures directly — pages are never re-rendered through an image pipeline, which is why merges, splits and rotations are lossless and fast.

Honest limits of the approach

• Memory is the ceiling. Your file is processed in your tab’s RAM. Hundreds of megabytes: fine on a normal computer. A 2 GB scanned archive: not the right tool.
• Encrypted PDFs can’t be edited. Password-protected files would need the password and a decryption step we deliberately keep out of scope; the tools tell you instead of failing quietly.
• Speed depends on your device. There’s no server farm — a ten-year-old laptop compresses a 200-page scan slower than a new one. (It also never waits in an upload queue, so in practice local usually wins.)
• JavaScript is required. The engine is JavaScript. With it disabled, the tools can’t run — that’s the trade for having no server.

Offline as proof

Once loaded, the site works with no connection at all — you can install it as an app and use it in airplane mode indefinitely. Offline capability isn’t a convenience feature here; it’s a standing demonstration that the processing is local. A tool that uploads simply cannot work offline.