5 PDF Security Risks Most People Ignore
Most people treat PDFs like printed paper — static, safe, final. They're not. PDFs are complex file formats with a long history of security problems. And the tools people use to handle them add more risks on top.
Here are five that don't get enough attention.
## 1. Uploading to Cloud Tools for "Simple" Operations
You need to merge two PDFs. You go to ILovePDF or Smallpdf, upload both files, and get the merged result back. Simple. Easy. Done.
But both files just traveled to a server you don't control. They sat there for however long the processing took. They may sit in a queue before processing. They exist in backups you can't audit.
For a school newsletter, that's fine. For a merger agreement with NDA language? That's a problem.
The underappreciated part: cloud PDF tools are high-value targets for attackers. Millions of confidential documents, all funneling through the same infrastructure. ILovePDF was compromised in 2019. That's documented. It happened.
Client-side tools — ones that run entirely in your browser — avoid this entirely. Your files never leave your device. The WiFi test reveals which tools are which: turn off WiFi and try the tool. If it works, your files are staying local.
## 2. Metadata That Reveals More Than You Think
PDFs carry metadata. The author's name. The software used to create the file. The date it was created — and the date it was last modified.
That last one is the dangerous one. If you send a contract claiming it was finalized on March 1st but the PDF metadata shows it was edited on March 14th — someone can check.
Beyond dates: revision history. Some PDFs retain previous versions inside the file, visible to anyone with the right tools. Some retain comments that were "deleted." Some retain the names of everyone who reviewed the document.
Most people never think about this. Professional document review workflows often catch it. But if you're sending PDFs without stripping metadata first, you're potentially revealing information you think you removed.
## 3. Fake Redaction
This is the big one. It's embarrassing how often it happens.
"Redacting" a PDF by drawing a black rectangle over text doesn't remove the text. It covers it. The underlying text is often still there — selectable, searchable, copy-pasteable.
The correct way to redact is to burn the visible content into the page as a flat image, making the underlying text layer inaccessible. Most PDF editors don't do this by default. Some that claim to offer redaction don't actually do it properly.
The consequences can be severe. In 2021, a court filing by a major law firm accidentally exposed sensitive information through exactly this failure — black boxes over text that was still readable in the underlying file.
If you're redacting documents for legal, regulatory, or confidentiality reasons — verify that your tool is doing actual redaction, not just visual overlay.
## 4. Weak or Non-Existent Encryption
Not all PDF passwords are equal.
Older PDF encryption standards — PDF 1.x using RC4 40-bit or 128-bit encryption — can be cracked in minutes with freely available tools. Passwords set with these standards offer essentially no protection against a motivated attacker.
The current standard is AES-256. PDF 2.0 uses it. If you're encrypting a PDF and your tool doesn't specify AES-256, you should find out what it's actually using.
Equally common: people set "open" passwords (requiring a password to view) but not "permissions" passwords (restricting printing, editing, copying). Or vice versa. Understanding the difference matters if you're using encryption for document control rather than just access control.
We use AES-256 for all PDF encryption in our tools. That's not a marketing claim — it's the specification. You can verify it by checking the encrypted file's properties in any PDF reader.
## 5. Shared Links With Permanent Access
PDF storage and sharing tools — Google Drive, Dropbox, DocSend — often generate shareable links that don't expire by default.
You send a link to a contract. The deal closes. Six months later, that link still works. The recipient forwarded it to someone on their team. That person left the company. The link is still active. Your document is still accessible.
This is a process risk as much as a technical one, but it's common. Shared links feel temporary. They often aren't.
The discipline is: set expiration dates on shared links, require authentication to view sensitive documents, and audit access after deals close.
---
The common thread across all five: the biggest PDF security risks aren't about the PDF format itself. They're about the tools people use to handle PDFs, and the assumptions people make about how those tools work.
Verify your tools. Test what actually happens to your files. And for anything confidential — use a tool that keeps files on your device.
[Try WhisperDocs](/merge-pdf) — client-side processing, AES-256 encryption, proper redaction. Everything in your browser, nothing on our servers.
Here are five that don't get enough attention.
## 1. Uploading to Cloud Tools for "Simple" Operations
You need to merge two PDFs. You go to ILovePDF or Smallpdf, upload both files, and get the merged result back. Simple. Easy. Done.
But both files just traveled to a server you don't control. They sat there for however long the processing took. They may sit in a queue before processing. They exist in backups you can't audit.
For a school newsletter, that's fine. For a merger agreement with NDA language? That's a problem.
The underappreciated part: cloud PDF tools are high-value targets for attackers. Millions of confidential documents, all funneling through the same infrastructure. ILovePDF was compromised in 2019. That's documented. It happened.
Client-side tools — ones that run entirely in your browser — avoid this entirely. Your files never leave your device. The WiFi test reveals which tools are which: turn off WiFi and try the tool. If it works, your files are staying local.
## 2. Metadata That Reveals More Than You Think
PDFs carry metadata. The author's name. The software used to create the file. The date it was created — and the date it was last modified.
That last one is the dangerous one. If you send a contract claiming it was finalized on March 1st but the PDF metadata shows it was edited on March 14th — someone can check.
Beyond dates: revision history. Some PDFs retain previous versions inside the file, visible to anyone with the right tools. Some retain comments that were "deleted." Some retain the names of everyone who reviewed the document.
Most people never think about this. Professional document review workflows often catch it. But if you're sending PDFs without stripping metadata first, you're potentially revealing information you think you removed.
## 3. Fake Redaction
This is the big one. It's embarrassing how often it happens.
"Redacting" a PDF by drawing a black rectangle over text doesn't remove the text. It covers it. The underlying text is often still there — selectable, searchable, copy-pasteable.
The correct way to redact is to burn the visible content into the page as a flat image, making the underlying text layer inaccessible. Most PDF editors don't do this by default. Some that claim to offer redaction don't actually do it properly.
The consequences can be severe. In 2021, a court filing by a major law firm accidentally exposed sensitive information through exactly this failure — black boxes over text that was still readable in the underlying file.
If you're redacting documents for legal, regulatory, or confidentiality reasons — verify that your tool is doing actual redaction, not just visual overlay.
## 4. Weak or Non-Existent Encryption
Not all PDF passwords are equal.
Older PDF encryption standards — PDF 1.x using RC4 40-bit or 128-bit encryption — can be cracked in minutes with freely available tools. Passwords set with these standards offer essentially no protection against a motivated attacker.
The current standard is AES-256. PDF 2.0 uses it. If you're encrypting a PDF and your tool doesn't specify AES-256, you should find out what it's actually using.
Equally common: people set "open" passwords (requiring a password to view) but not "permissions" passwords (restricting printing, editing, copying). Or vice versa. Understanding the difference matters if you're using encryption for document control rather than just access control.
We use AES-256 for all PDF encryption in our tools. That's not a marketing claim — it's the specification. You can verify it by checking the encrypted file's properties in any PDF reader.
## 5. Shared Links With Permanent Access
PDF storage and sharing tools — Google Drive, Dropbox, DocSend — often generate shareable links that don't expire by default.
You send a link to a contract. The deal closes. Six months later, that link still works. The recipient forwarded it to someone on their team. That person left the company. The link is still active. Your document is still accessible.
This is a process risk as much as a technical one, but it's common. Shared links feel temporary. They often aren't.
The discipline is: set expiration dates on shared links, require authentication to view sensitive documents, and audit access after deals close.
---
The common thread across all five: the biggest PDF security risks aren't about the PDF format itself. They're about the tools people use to handle PDFs, and the assumptions people make about how those tools work.
Verify your tools. Test what actually happens to your files. And for anything confidential — use a tool that keeps files on your device.
[Try WhisperDocs](/merge-pdf) — client-side processing, AES-256 encryption, proper redaction. Everything in your browser, nothing on our servers.