RectoPDF
English
· RectoPDF team

Why we built our PDF tools to run in your browser

An honest take on the privacy/performance tradeoff of WASM-based PDF tools — and why uploading files to do simple operations is a bad default.

Every major online PDF tool — iLovePDF, Smallpdf, Sejda, PDF24 — works the same way: you upload your file, their servers process it, you download the result. It works. It’s also a weird default that nobody questions.

We do this differently. Every free tool on RectoPDF runs entirely in your browser. No upload, no server-side processing, no “we deleted your file after 30 minutes.” There’s nothing to delete because there’s nothing to receive.

This post explains why we made that choice, what it costs you (yes, there are tradeoffs), and what you actually get.

The hidden cost of the upload model

When you upload a PDF to a “free online” tool, several things happen:

  1. Your file travels across the network. If it’s sensitive — a contract, a medical bill, an internal report — it’s now in flight, then briefly on someone else’s disk.
  2. The server processes it. That server has logs. It has crash dumps. It has backups. The “deletion policy” usually only applies to the primary copy.
  3. You implicitly trust the operator’s claims. Most are reputable. Some have had breaches. The privacy guarantee is at best “we promise.”

For free tools, “free” almost always means your file is fine but the data trail isn’t. You’re trusting a vendor’s promise. With smaller operators, that promise is one config change or one breach away from being false.

For a public, non-sensitive PDF, none of this matters. For an HR document, contract, financial statement, or anything you’d rather keep private — it matters a lot. And the friction of “well I’ll just upload it real quick” is the friction of slowly normalising sending private documents to strangers’ servers.

What changed: browsers got powerful

The reason no one did this in 2015 is that browsers couldn’t. PDF manipulation needs:

  • A parser/serializer for the PDF format (kilobytes of code, but precise).
  • Compression libraries (Flate, LZW, JPEG).
  • For some tools: cryptography (AES, MD5, key derivation).
  • For some tools: image decode/encode (PNG, JPEG, JP2, TIFF).

All of this used to require native code on a server. Around 2020, two things converged:

  • WebAssembly matured. Native code compiled to WebAssembly runs at near-native speed inside browser tabs.
  • Mature PDF libraries now exist for both JavaScript and WebAssembly runtimes, producing clean, standards-compliant output.

Suddenly the same operations a server was doing could be done in your tab. There’s no longer a technical reason to upload — only inertia.

What you give up (and don’t)

You give up:

  • Multi-device sync. If you need a tool to “process a PDF on your phone and download on your laptop,” that requires a server. Most PDF operations don’t.
  • Very large files. Browser memory is constrained — a 1 GB PDF won’t open in a tab. For typical office documents (1–50 MB), this isn’t a real limit.
  • Operations we haven’t built yet. OCR, for instance, needs models that don’t fit in a small WASM module. We’ll get there.

You don’t give up:

  • Performance. WebAssembly is roughly as fast as native code. Our PDF compressor processes a 50 MB image-heavy PDF in 3–5 seconds — comparable to server-side tools, minus the network round-trip.
  • Functionality. Merge, split, compress, rotate, organize, image-to-PDF, Word-to-PDF, PDF-to-Word, password protect, unlock — all browser-only.
  • Format quality. We use the same libraries server-side tools use. The output PDFs are spec-compliant. They open in any reader.

The mental model

Treat browser-based tools the same way you treat a desktop app: it processes your files on your computer. The website is just a more convenient distribution channel than installing software. No account. No upload. No mailing list. No “your trial expires in 7 days.”

When something does need a server — a PDF too large for the browser, an integration with cloud storage, something that genuinely needs a long-running compute job — that’s what we’ll build as Pro tools. But “merge three PDFs into one” doesn’t need a server. So it doesn’t get one.

Tools you can try right now

  • Merge PDF — combine files locally, reorder by drag.
  • Split PDF — click pages to extract or split into separate files.
  • Compress PDF — shrink image-heavy PDFs right in your browser.
  • JPG to PDF — bundle images into a single PDF, with orientation and margin controls.
  • Protect PDF — AES-128 password protection that runs in your tab.

All free, all private by construction. The data never leaves because the data never goes anywhere.