Think about the last PDFs you handled: a signed contract, a bank statement for a visa application, a scanned ID, an invoice with your address on it. Now consider that "merge PDF online" is one of the most-searched tool queries in the world, and that most of the top results upload your documents to servers in unspecified countries with retention policies measured in "eventually."

This mismatch — maximally sensitive documents meeting minimally accountable tools — is why we built our PDF merger and images-to-PDF converter to run entirely in the browser. This article explains what that means technically and gives you a practical safety checklist for document tools in general.

What a PDF actually is

A PDF is not an image — it's a container document: a tree of objects (pages, fonts, images, vector drawing commands, metadata) with a cross-reference table that says where each object lives in the file. This structure is what makes client-side merging feasible: combining two PDFs doesn't require understanding or rendering their content. A merge tool reads each file's object tree, copies the page objects (with the fonts and images they reference) into a new document, and writes a fresh cross-reference table. No OCR, no rasterizing, no server-grade compute — just careful bookkeeping that a phone's browser handles in milliseconds.

JavaScript libraries (the pdf-lib family being the best known) implement exactly this: parse, copy pages, reassemble, save — all in the browser's memory, using the same File and Blob APIs that power client-side image tools.

The threat model: what can actually go wrong with upload-based tools

Being concrete beats being scared. When you upload a document to a processing service, the realistic risks are:

  • Retention beyond the stated window. "Files deleted after 2 hours" is a policy, not a property you can verify. Backups, logs, and error-handling paths routinely outlive the policy.
  • Breach of the service itself. Document-tool services are attractive targets precisely because their upload buckets are dense with IDs, contracts, and financial records.
  • Jurisdiction. Your document is subject to the laws — and lawful-access regimes — of wherever the server sits, which the tool rarely discloses.
  • Metadata leakage. Even if content handling is honest, access logs (your IP, filenames like salary-slip-march.pdf, timestamps) tell a story on their own.

None of these risks requires malice by the tool's operator — ordinary sloppiness suffices. And all four disappear entirely when the file never leaves your machine.

How to verify a tool is local (60 seconds)

  1. Network tab: open DevTools → Network, use the tool, and watch for a request whose size matches your file. A local tool shows none.
  2. Airplane mode: load the page, go offline, process the file. Local tools work; upload tools fail.
  3. Speed sanity check: a 30 MB scan that merges "instantly" on hotel Wi-Fi wasn't uploaded anywhere.

These tests are definitive in a way that privacy-policy prose never is — they observe what the tool does rather than what it says.

Practical guidance by document sensitivity

  • Low stakes (public documents, brochures): use whatever is convenient.
  • Medium stakes (invoices, coursework, CVs): prefer verified client-side tools — the one-minute check above is cheap insurance.
  • High stakes (IDs, contracts, medical and financial records): verified client-side tools or offline software only. On the desktop, macOS Preview merges PDFs natively; LibreOffice and PDFsam handle it on every platform.
  • Regulated data (patient records, client legal files): your employer's approved tooling, full stop — professional obligations usually prohibit third-party processing regardless of the tool's technical design.

Two adjacent tips people ask about

Scans into one PDF: the photos-to-PDF workflow (photograph each page, combine into a single document) also runs fully client-side in our images-to-PDF tool — the same privacy logic applies, and it's usually the fastest way to "scan" without a scanner.

Reducing PDF size: most oversized PDFs are oversized because of embedded photos. Compressing the images before assembling the PDF (rather than compressing the finished PDF) gives better quality at smaller sizes — image compression is a solved, controllable problem, while whole-PDF compressors make opaque decisions about every object in the file.

The uncomfortable truth about document tools is that convenience trained us to upload first and think later. The tools caught up — the browser you're reading this in can do the work locally now. All that's left is choosing tools that actually do.