Why you shouldn't upload PDFs to random online tools

Picture the scene: you’ve got three PDFs you need to combine for an email. You Google “merge PDF online,” click the first result, upload your files, download the merged output, and move on with your day. Total time: 90 seconds.

What you may not have considered is who else just touched your documents.

For most people, most of the time, uploading is fine. But there are specific categories of document where uploading is a bad idea, and a free alternative — browser-based processing — exists that removes the risk entirely.

What actually happens when you upload

When you drop a PDF onto a typical online tool, here’s the sequence:

1. Your browser transmits the file over HTTPS to the tool’s server. Encryption in transit is standard.
2. The server writes the file to disk, usually in a temporary directory identified by a random ID.
3. A backend process reads the file and performs whatever operation — merge, convert, compress, split.
4. The output is written to disk in the same temporary area.
5. The server sends you a download link, often with a short-lived token.
6. Eventually, files are deleted — usually within 1-24 hours, sometimes longer.

At steps 2-6, your document exists on someone else’s infrastructure, typically a shared cloud server. Anything that touches that server — the tool’s own code, any staff with access, any backup system, any logging pipeline, any attacker who breaches the service — has access to your file.

This is true of essentially every online tool. It’s not sinister; it’s just how web applications work.

What the tool’s privacy policy actually promises

Most online PDF tools have a privacy policy saying one of these things:

• “Files are deleted within 1 hour” (the good ones)
• “Files are deleted within 24 hours” (the typical ones)
• “Files are deleted after processing” (vague; usually still means 1+ hours)
• No specific promise (worst)

Notably absent from most policies: whether backups retain the file longer than the primary storage (almost always yes), whether employees can access the file during its retention window (usually yes, for debugging), whether file metadata is logged separately and kept longer (often yes — filenames, sizes, timestamps, IP addresses), and whether the content of the file is analysed for product improvement or AI training (some tools yes, some no).

For a random recipe PDF, none of this matters. For a confidential contract, it absolutely does.

The real-world attack surface

There are three plausible ways your document can leak from an online tool.

The service is deliberately harvesting data. Some free tools exist specifically to collect the content that passes through them. The business model is “free tool, paid dataset.” This is rare among the top-ranked results — they’re usually legitimate ad-supported services — but common among the long tail of smaller tools. Without auditing the source and server setup, you can’t tell which is which.

A security breach exposes stored files. Services get breached. In 2020, a popular online PDF tool was found to be serving files with predictable URLs — a third party could download anyone else’s documents just by guessing. Similar issues have happened at multiple services over the years. Even if the service itself is entirely legitimate, the files sitting on their disk are a target.

Staff access. For debugging, customer support, or product improvement, staff at most tools can access uploaded files during their retention window. Most staff are trustworthy; it only takes one who isn’t.

Which documents matter

Not all PDFs carry the same risk. Think about what’s in your file before deciding whether uploading is acceptable.

Definitely don’t upload:

• Signed contracts and legal agreements
• Tax documents, financial statements, invoices with bank details
• Medical records and insurance documents
• Government-issued IDs, passport scans
• Anything covered by a confidentiality clause with a client
• Internal company documents labelled confidential
• Employee personal data (GDPR, HIPAA, etc.)
• Anything containing SSNs, credit card numbers, or other direct PII

Probably fine to upload:

• Public reports, whitepapers, marketing materials
• Documents already published online
• Recipes, travel itineraries, user manuals
• Drafts with no sensitive content

Grey zone — decide case by case:

• CVs / resumes (contains personal data)
• Personal photographs converted to PDF
• Correspondence with companies (may contain account numbers)
• Academic papers (usually fine unless unpublished)

When in doubt, assume the document matters and use a local tool.

The safer alternative: local processing

PDFs can be manipulated entirely within the browser, with no server involved. Modern browsers are powerful enough to run full PDF libraries locally — the PDF Merge tool is an example.

The model is: you open the page, your browser downloads the tool’s JavaScript, you drop your PDFs onto the page, everything happens in your browser’s memory — reading, processing, writing — and you download the output. The file never leaves your computer. There’s no server behind the scenes that could leak, log, or archive your content.

How to tell if a tool runs locally

A few quick checks:

Read their privacy policy. A tool that runs locally should explicitly say “no files are uploaded” or “processing happens in your browser.”

Open DevTools → Network tab before using the tool. Start a merge, compress, or convert operation. If you see a POST request uploading your file, it’s server-side. If all network activity stops after the initial page load, it’s local.

Test with the network disconnected. Disable Wi-Fi after loading the page, then try to process a file. A local tool will still work. A server-based tool will fail.

The DevTools check takes about 30 seconds and is a good habit to get into.

Performance trade-offs

Local processing isn’t magically faster in all cases.

Pros of local processing: no upload/download time (for a 10 MB file on a slow connection, that’s a real saving), no server queue (popular tools sometimes make you wait during peak hours), no file size limits imposed by the service (only by your browser’s memory), and no privacy risk.

Cons: your browser does the work, so large files take local CPU time. Some operations (OCR on scanned pages, complex image processing) are faster on server-side tools with specialised hardware. The first page load downloads the tool’s code, which is bigger than a static form.

For merging, compressing, and converting most day-to-day files, local is faster and safer. For heavy industrial workflows (batch OCR on 10,000 scans), server-side tools still have their place.

A simple rule to remember

Before uploading any PDF to any online tool, ask: would I be comfortable emailing this document to a stranger?

If yes, upload is fine. If no, use a local tool.

It’s a crude rule but it works. Most of the documents you’re tempted to upload are ones you’d actually be uncomfortable sending to a stranger — that contract, that tax form, that customer spreadsheet. The online tool is just a stranger with a convenience interface.

---

The PDF Merge tool is a practical demonstration of local processing. Open DevTools, switch to the Network tab, and run a merge. You’ll see the page load its JavaScript, and then nothing else — no uploads, no server calls. The merged file shows up in your downloads folder having never left your laptop.

Same goes for the Image Compressor, JSON Formatter, and Base64 encoder. All local, all private by construction.