PDF Privacy — Why Browser-Based Editing Matters

GN PDF · January 28, 2026 · 11 min read · Privacy· Security

What "free online PDF tool" usually means architecturally

You click Upload.
Your file is HTTP-POSTed to the service's API.
It lands in a temporary directory on a processing server. Maybe ephemeral, maybe persistent.
A worker process opens the file, does the requested operation, writes the output.
The output is uploaded to an S3-style bucket. A signed URL is returned to your browser.
The service "deletes the file after X hours" — but you have no proof of this.

Every step in that chain has logs, caches, and snapshots. Most of those backups exist for legitimate operational reasons; none of them are designed with your specific privacy in mind.

What "browser-based" actually means

In a properly built client-side PDF tool, the architecture flattens to:

You drop a file onto the page.
The browser reads the file's bytes into JavaScript memory.
JavaScript libraries (pdf.js, pdf-lib, fabric.js) process the bytes.
The browser writes the result back to your Downloads folder.

That's it. There is no API call carrying your file. There is no temp directory. There is no S3 bucket. There is no signed URL.

"How do I verify this?"

Excellent question — and the answer is built into your browser:

Open the editor in a new tab.
Press F12 to open DevTools.
Click the Network tab.
Drop your file into the editor.
Edit it. Hit Apply, Download.
Look at the Network panel: zero outgoing requests carry the file's bytes. The only outgoing traffic is fonts, the small JS libraries, and maybe an ad — all loaded at page-open, not when you process the file.

This is the kind of verification that's impossible with server-side tools. The architecture itself is the privacy guarantee.

Why this matters more in 2026 than ever before

Three concurrent trends:

Document AI is everywhere. Many "free" PDF services now feed your file through an AI summariser, classifier or OCR pipeline. Sometimes that's the point — sometimes it's a quiet bonus to train their models. Either way, your salary slip becomes training fodder.
Data-breach baseline is bad. Even responsible companies leak. If a free PDF site you used in 2023 has its S3 bucket misconfigured today, your old PDFs may surface in a paste somewhere.
Per-document tracking. Pixel beacons, file hashes used as IDs, and "share this file" links that quietly track openings — these are normalised on many large "free" platforms.

The practical rule

Use a server-side PDF tool only for documents you are happy to publish on the front page of a national newspaper. Use a browser-based tool for everything else.

What GN PDF does to keep its promise

The entire core editor and 80% of the toolkit run client-side. No server processing path exists in our codebase for these tools.
Files you save to the Image Library are stored in IndexedDB on your device. We never sync them.
Our privacy policy is six sentences — because there isn't much to say.
Our analytics are page-view counts only; we have no idea what your file contained, because the bytes never reach us.

What about ads?

We do show display ads on supporting pages. Those ads are served by Google AdSense; they have their own cookie policies. Crucially: we don't pass them any document contents — because we don't have them. Ads see the same anonymous page-view that any other visitor's browser would generate.

Closing

If you've ever sent a salary slip through a "free PDF" tool and immediately regretted it, this post is for you. Use a browser-based editor next time — you'll forget what server-side limits felt like.