The Complete Guide to PDF Security: Passwords, Encryption, Redaction, and Digital Signatures

PDFs Carry Secrets — Most People Protect Them Badly

PDFs are the default format for sensitive documents: contracts, tax returns, medical records, legal briefs, financial statements, corporate filings, and government forms. Yet most people securing these documents make mistakes that leave them exposed. A "password-protected" PDF may use RC4 encryption that was broken in 2015. A "redacted" document may still have selectable text under those black boxes. An "e-signed" document may have no protection against tampering after signing.

This guide covers everything you need to know to secure a PDF properly, organized by the threat each technique addresses.

Section 1: Password Protection

PDF password protection comes in two distinct types that are often confused.

User Password (Open Password)

Controls who can open the file. Without this password, the PDF content remains encrypted as ciphertext. A user password is real security — not advisory, not optional, not bypassable with a different PDF reader. If the document is encrypted with AES-256 and a strong password, it will remain unreadable until the correct password is supplied.

Owner Password (Permissions Password)

Controls what someone can do with the document after opening it — printing, copying text, editing, adding annotations, and filling forms. Here is the critical fact that most PDF users do not know: owner permissions are advisory, not enforced. Adobe Acrobat honors them. Most third-party PDF readers — including the built-in viewers in Chrome, Firefox, and Edge — ignore them entirely.

A document protected with only an owner password (no user password) is not actually secured. Anyone who opens it can bypass the printing and editing restrictions with any reader that does not enforce them. The owner password was designed for a world where everyone used Adobe Acrobat. That is not the world we live in.

Rule: Always set a user password. The owner password is a secondary convenience signal, not a security measure.

AES-256 vs AES-128 vs RC4

The PDF specification supports three encryption algorithms:

RC4 was the standard PDF encryption for nearly a decade, but cryptanalysis has advanced significantly since its introduction. In 2015, researchers demonstrated that RC4-encrypted PDFs can be decrypted with a known-plaintext attack in under a minute. Several tools exist that can strip RC4 encryption from PDFs in seconds.

AES-256, by contrast, is approved by the US National Security Agency for encrypting classified documents up to Top Secret level (when used with a 256-bit key in an approved mode, which CBC is). It is currently considered computationally infeasible to brute-force with any known or near-future technology.

Always choose AES-256 when protecting a PDF. Some older PDF readers do not support AES-256 — notably, Adobe Acrobat 7 and earlier, and some mobile readers from the 2010s. If compatibility with very old software is required, AES-128 is an acceptable fallback. Never choose RC4.

How PDF Encryption Actually Works

When you set a password on a PDF, the library does not encrypt the whole file as a single blob. Instead, every content stream inside the PDF — each page's text, each embedded image, each font program — is encrypted individually. The encryption key is derived from your password using a key derivation function that also incorporates the file's unique ID, ensuring that the same password applied to two different PDFs produces two different encryption keys.

AES-256 encryption (PDF 2.0) uses a six-step key derivation process that includes:

1. SHA-256 hashing of your password (preventing precomputation attacks)

2. Addition of the file's unique identifier (preventing the same password from producing the same key across files)

3. Repeated hashing with a 64-byte salt and a validation key (preventing brute-force acceleration via rainbow tables)

4. AES-256 encryption of the actual content streams in CBC mode (for confidentiality)

The result is that an attacker without the password sees not text, but ciphertext indistinguishable from random noise. Every content stream is individually encrypted, so the attacker cannot infer the structure of the document even from the encrypted data.

How Strong Should Your Password Be?

Attacking a PDF password typically involves either brute force (trying every possible password) or dictionary attacks (trying passwords from a list of common phrases). The resistance to both depends on your password:

• 8 characters, lowercase only: Broken via brute force in under 24 hours on consumer hardware.
• 10 characters, mixed case + digits: Broken in 6-12 months on consumer hardware; weeks on a GPU cluster.
• 14 characters, mixed case + digits + symbols: Effectively unbreakable via brute force with current technology. The keyspace is 95^14, or about 10^27 combinations.
• 16+ random characters from a password manager: Essentially permanent security against brute force.

For sensitive documents, use a password generated by a password manager: at least 14 characters, including uppercase letters, lowercase letters, digits, and symbols. Do not use dictionary words, dates, or phrases that could be guessed by someone who knows you.

Limitations of Password Protection

Passwords are the most common PDF security mechanism, but they have fundamental weaknesses:

• Passwords can be brute-forced if weak. Even with AES-256, a password like "John2023" falls to a dictionary attack in seconds.
• Passwords must be shared with every legitimate recipient. Once shared, that recipient can reshare the password (and the file) with anyone. There is no access revocation — changing the password requires re-encrypting and redistributing the document.
• No audit trail. There is no record of who opened the document, when, or how many times. If a leak happens, you have no way to trace it back to the source.
• Passwords can be intercepted during transmission. If you email the password separately from the document, the email can be intercepted. If you send both in the same email, the password protection is useless. The ideal mechanism is to share the password through a different channel (phone, encrypted messaging) or through a password manager's shared vault.

Section 2: Redaction — Permanent Removal of Content

Redaction is the most misunderstood PDF security operation. Drawing a black rectangle over text in a PDF viewer does not redact it.

The Black Box Problem

When you draw a rectangle over text using Preview, Chrome's PDF viewer, or even some versions of Adobe Acrobat's commenting tools, you are adding a shape annotation to the page. The text underneath remains in the PDF's content stream. Any reader that does not render annotations — or any tool that extracts text — will see the "redacted" text clearly.

This is not hypothetical. In 2019, the US Department of Justice inadvertently disclosed the name of a confidential informant because a court filing used black boxes drawn in Preview over text. The PDF metadata retained the original text. Anyone who extracted the plain text from the PDF could read the informant's name. The FBI had to investigate the leak culture in its own office before discovering the cause was not a leak at all — it was a redaction failure in a PDF that a government employee had believed was properly secured.

Similar incidents have occurred at Apple (product specifications redacted with black boxes, text still extractable), multiple law firms (client names in court filings), and at least one federal agency (social security numbers in a FOIA release).

True Redaction

True redaction permanently removes content from the PDF's structure. The operation works at the content stream level:

1. The tool identifies the specific content — text characters, image pixels, vector paths — within the area to be redacted.

2. Those content objects are removed from the page's content stream. Not covered, not hidden — removed.

3. The remaining content is recompiled into a new content stream for that page.

4. A solid rectangle may be placed where the removed content was (optional, but standard practice for producing a visibly redacted document).

After true redaction, there is no way to recover the removed content. The PDF no longer contains the data. Even tools that bypass rendering and directly parse the content stream will find nothing because the content does not exist.

How to Verify Redaction Is Real

Before sharing a redacted PDF, verify that the redaction is effective:

1. Try to select the redacted area. Open the PDF in any reader and drag to select text where the redaction appears. If any text is selectable, the redaction failed.

2. Copy and paste the surrounding area. Select text near the redaction mark and paste it into a text editor. If any redacted text appears in the paste, the redaction failed.

3. Extract the raw text. Use a tool like pdftotext (part of Poppler) to dump the PDF's text content: pdftotext document.pdf -. Search the output for terms that should have been redacted. If they appear, the redaction failed.

4. Inspect the page content stream. Open the PDF in a text editor or use a PDF structure inspector. Search for the redacted terms in the uncompressed content. If they appear, the redaction failed at the content stream level.

On pdfprivately, the Redact PDF tool performs true content-stream-level redaction. The redacted text is permanently removed and cannot be recovered from the output file.

Famous Redaction Failures

These real-world cases illustrate how costly redaction mistakes are:

2019 — DOJ informant exposure. As described above, the Department of Justice used black-box annotation redaction on a court filing. The text underneath was fully recoverable. The FBI initially launched an internal leak investigation.

2018 — Apple product specifications. Apple filed a court document in a patent case with product sales numbers redacted using black boxes in Word. The redacted text was still readable in the PDF metadata. The numbers were published by news outlets within hours.

2016 — Samsung legal filing. Samsung's legal team redacted financial data from a court filing using black highlight in Word. The text was preserved in the document metadata. Opposing counsel could read the redacted figures.

2013 — IRS FOIA response. The IRS redacted portions of a document released under FOIA by covering text with white boxes. Someone selected the text, copied it, and pasted it into a new document, recovering all the "redacted" text.

The common thread: someone believed visual obfuscation was equivalent to data removal. It is not.

Redaction Checklist for Sensitive Documents

Before sharing any PDF containing information that must not be disclosed, follow these seven steps:

1. Use a tool designed for redaction, not a PDF viewer's annotation tools. The tool must modify the content stream, not overlay annotations.

2. Redact each piece of content twice. Apply the redaction, then verify by attempting to select, copy, and search for the content. Errors happen. Verification catches them.

3. Redact metadata too. PDFs store metadata — author name, creation date, editing application, document title — that can identify or expose information about the document. Use the Edit Metadata tool or a PDF optimizer to clean metadata fields before sharing.

4. Check for hidden layers. Some PDFs contain layers (OCTG — Optional Content Groups) that can hide visible content but remain in the file. Flatten all layers before redacting.

5. Remove annotations and comments. Comments, sticky notes, and markup annotations may contain the very information you are redacting. Use the Remove Annotations tool before redacting.

6. Consider flattening the PDF. Flattening merges all content layers and annotations into a single content layer and removes form fields. Redact after flattening for maximum assurance.

7. Test on a copy. Redact a copy of the document, not the original. If the redaction tool has a bug, the original remains intact.

Section 3: Certificate Encryption

For environments where passwords are not secure enough, PDF supports certificate-based encryption using public key infrastructure (PKI). Instead of encrypting the document with a password, you encrypt it with the public key of each intended recipient. Each recipient uses their private key to decrypt the document.

Certificate encryption solves several problems with passwords:

• No password to share. The document is encrypted to specific recipients. Only they can open it, using their private key.
• Audit trail. The certificate infrastructure can log who accessed what document and when.
• Revocation. If a recipient should no longer have access, their certificate can be revoked. The next time they attempt to open the document, their revoked certificate will not decrypt it.
• Non-repudiation. Because the decryption key is tied to a specific identity, recipients cannot plausibly deny accessing the document.

The downside is complexity. Certificate encryption requires a PKI infrastructure, which means a certificate authority to issue and manage certificates, a directory to publish certificates, and client configuration for each user. Most organizations that use certificate encryption deploy it through Adobe LiveCycle or a similar enterprise document management platform.

For individual users, password-based protection with a strong password is more practical and provides equivalent security for most use cases.

Section 4: Digital Signatures vs Electronic Signatures

These terms are often used interchangeably, but they refer to completely different things:

An electronic signature is a visual representation on the page. It proves intent to sign. It does not prove that the document has not been altered since signing.

A digital signature is a cryptographic hash of the document, encrypted with the signer's private key. If a single byte of the document changes after signing, the hash no longer matches, and the digital signature shows as invalid. This is the PDF equivalent of tamper-evident tape.

For most business documents, an electronic signature is sufficient — the law recognizes intent, and disputes over document integrity are rare. For documents where tampering is a genuine concern (contracts with large financial stakes, regulatory filings, certificates, and licenses), a digital signature provides cryptographic proof that the document received is the document signed.

Section 5: PDF Metadata — The Overlooked Leak

Every PDF carries metadata: author name, document title, creation date, modification date, editing application, and sometimes revision history. This metadata is visible to anyone who opens the document and selects File > Properties (or equivalent).

Common metadata leaks:

• Author name set to your system username. When you create a PDF from Word or Google Docs, the author field defaults to your system login name. If your username is "JohnDoe" or "jsmith@company.com," that leaks your identity or email address to anyone who inspects the document.
• Editing application reveals your tools. PDFs created with your employer's document management system may embed that system's name in the Creator field. This can be useful information for competitors analyzing your documents.
• Revision history from collaborative editing. Some PDFs preserve revision marks, tracked changes, and comments from the editing process, even when you think you exported a clean copy.

Before sharing a PDF externally, inspect and clean its metadata. On pdfprivately, the Edit Metadata tool lets you view and modify all metadata fields. Remove or genericize fields that could leak information:

• Set Author to something generic: "Author" or your organization name without identifying details.
• Set the Subject and Keywords fields only if they are helpful to the recipient.
• Remove any custom metadata properties that were added by your document management system.

Section 6: Client-Side Security — Your Files Never Leave Your Device

Every security operation described in this guide — password protection, AES-256 encryption, redaction, metadata cleaning, digital signing — can be performed entirely in your browser using client-side tools like those on pdfprivately.

This matters for PDF security in a way that most people do not consider. When you upload a sensitive document to a server-based PDF tool to encrypt or redact it, you are exposing the document at exactly the moment you are trying to protect it. The document you want to secure from unauthorized access is transmitted over a network, stored on a third-party server, processed by software you did not write, and then delivered back to you. The server operator could log, retain, or inspect your document despite promises of privacy.

Client-side security inverts this. The document never leaves your device. The encryption, redaction, or metadata cleaning code is downloaded to your browser and executed on your CPU. Your file is read from your filesystem into browser memory, processed there, and downloaded back to your filesystem. There is no network transmission of file content. There is no third-party server that could be breached, subpoenaed, or audited.

A PDF that was password-protected on a server-based tool existed on that server as plaintext during processing. A PDF that was password-protected on a client-side tool remained encrypted on your device at all times — the plaintext existed only within the address space of your browser's tab.

This is the fundamental security property of client-side processing, and it is relevant to every technique discussed in this guide. Your PDF security should not depend on trusting another party. With browser-based tools, it does not have to.