PDF Security, Honestly: Passwords, Permissions and Real Redaction

PDF has several features that sound like security and provide very different levels of it. Confusing them is how confidential text ends up published under a black box that anyone can copy and paste out of.

User passwords: real encryption

A user password (open password) means the file's contents are encrypted. With AES-256 and a strong password, this is genuine protection — without the password the bytes are noise. This is the only PDF security feature that stands up to a determined attacker.

The caveats are the usual ones for any encryption: the strength is the password, not the algorithm. A six-character password on AES-256 is a six-character password. And if you email the file and the password in the same thread, you have encrypted nothing.

Owner passwords and permissions: not security

Permission flags — no printing, no copying, no editing — are requests. The file is readable; the flags simply ask compliant software to restrict what it offers the user. Any non-compliant reader ignores them entirely. Use permissions to prevent accidents and signal intent, never to protect a secret.

Redaction: the one people get wrong

Drawing a black rectangle over text adds a black rectangle. The text is still there, underneath, fully selectable and fully searchable. This exact mistake has produced court filings, government disclosures and corporate documents where the confidential content was recoverable by pressing Ctrl+A.

Real redaction removes the underlying content objects and then draws the marking. After redacting, verify by selecting all text on the page and pasting it somewhere plain — if the redacted string appears, the file is not redacted.

The metadata nobody checks

• Author, company and title fields, often left from the original template's owner.
• Revision history in files exported from word processors with tracked changes enabled.
• Embedded thumbnails generated before the redaction was applied.
• Attached files and embedded objects that are not visible on any page.
• Layers (OCGs) that are hidden but present — hiding a layer is not removing it.

A pre-release checklist for sensitive documents

1. Apply true redaction, not annotation.
2. Select-all and paste into a text editor; confirm no redacted content appears.
3. Strip document metadata and set fresh title/author values.
4. Flatten layers and annotations.
5. Regenerate the file so thumbnails and cached previews are rebuilt from the redacted content.
6. If it must be encrypted, use AES-256 with a long passphrase and deliver the passphrase out of band.

Where browser-side processing helps

For genuinely sensitive documents, the strongest privacy property is that the file never leaves your machine. Tools that run in the browser via WebAssembly do the work locally — there is no upload to intercept, no server copy to subpoena, and nothing to retain. That is a structural guarantee rather than a policy promise, and for legal and medical documents it is worth insisting on.

A step-by-step walkthrough: releasing a redacted contract externally

Take a common scenario: a signed commercial contract needs to go to a regulator with pricing terms and a named individual's personal details removed, while everything else stays intact and legible.

1. Work from the signed original, not from a copy that has already had annotations, comments, or a prior attempted redaction layered on top — starting from a clean source avoids inheriting stray hidden content from earlier edit passes.
2. Identify every occurrence of the sensitive terms across the whole document, not just the obviously visible ones — pricing figures often repeat in a summary table, an appendix, and a signature page footer, and missing one occurrence defeats the entire exercise.
3. Apply redaction marks over each occurrence using a tool that removes the underlying text and image content, not one that only draws an opaque shape on top of the existing content layer.
4. Apply the redaction, which should rewrite the page content stream so the marked text and any images beneath the mark are actually deleted from the file, not merely obscured visually.
5. Select all text on every redacted page and paste it into a plain text editor. Confirm the redacted terms do not appear anywhere in the pasted output, including in a different case or with different spacing than expected.
6. Strip document metadata: title, author, company, and any custom properties that might identify the source system or an internal case reference number.
7. Check for and remove hidden layers, embedded file attachments, and any earlier annotation history that a word processor or PDF editor may have retained from previous drafts.
8. Regenerate thumbnails and any cached preview images so nothing pre-redaction survives in a preview pane, since some viewers cache a rendered thumbnail from before the edit was applied.
9. If encryption is warranted on top of redaction, apply AES-256 with a passphrase delivered through a separate channel from the document itself.

What real redaction failure looks like in practice

• A black box over text where selecting all text on the page and pasting still returns the covered string — the content object was never deleted.
• A redacted PDF where the search function still finds the redacted term, because search indexes the underlying text content stream, not the visual rendering.
• A document where the visible page shows redaction but an embedded thumbnail, generated before redaction, still shows the original unredacted content in a file browser preview pane.
• A PDF where a hidden optional content group (layer) still contains the original unredacted version of a page, toggled off by default but present in the file and re-enableable by any reader that exposes layer visibility controls.

Common mistakes

• Treating 'no printing' and 'no copying' permission flags as if they protect confidentiality — they do not encrypt anything and are trivially bypassed by any non-compliant reader or a simple print-to-PDF pass.
• Redacting a scanned image of a document by drawing over the image without OCR-checking whether a text layer sits underneath it — a searchable text layer added by a prior OCR pass can retain the original text even if the visible image is redacted.
• Sending the password for an encrypted file through the same channel as the file itself, which removes essentially all of the protection encryption was meant to provide.
• Assuming a document is 'clean' because it looks clean when opened in one particular PDF viewer — different viewers expose different metadata and layer information, and a thorough check requires inspecting the raw content, not just visual appearance in one tool.

Troubleshooting

Redacted text still shows up in search

This confirms the redaction tool only drew a visual mark rather than removing content objects. The fix is not a different visual style of redaction; it requires a tool that edits the underlying content stream, then a fresh select-all-and-paste verification pass on the output.

Encrypted file opens without a password on some devices

Some PDF viewers and preview panes cache a previously decrypted version, or the file was re-saved without the password by whoever last had it open. Verify encryption by opening the file fresh, from disk, in a viewer with no prior session state, on a device that has not previously opened the file.

Metadata still shows internal identifiers after cleanup

Custom metadata properties, sometimes added by document management systems for internal tracking, are stored separately from the standard title and author fields and are not always cleared by a generic 'remove metadata' function. Check for and clear custom XMP properties specifically, not just the standard document information dictionary fields.

Edge cases

• Forms with fillable fields that retain their original values in the field's underlying value even after the visible display is cleared — clearing what is shown is not the same as clearing what is stored in the field object.
• Documents that embed other files, such as a spreadsheet attached to a PDF report — attachments are not covered by page-level redaction at all and need to be checked and removed separately.
• Digitally signed documents where redaction after signing invalidates the signature, meaning the correct order is to redact first and sign last, not the reverse.
• Documents converted from a source format that embeds revision history, such as a word processor file with tracked changes, exported to PDF without accepting all changes first — the PDF export can sometimes retain deleted-but-tracked content in hidden form.

Standards reference

PDF encryption is defined within ISO 32000-2, which specifies the supported algorithms including AES-256, the security handler mechanism, and the distinction between the user password that gates opening the file and the owner password that gates permission flags — this is the specification-level basis for why permissions are enforceable only by compliant readers rather than being a cryptographic guarantee. There is no single universal redaction standard, but government and legal guidance in multiple jurisdictions, including guidance published by national archives and courts on electronic filing, converges on the same requirement described here: removal of underlying content, not visual masking.

When not to rely on PDF security features at all

If a document must never be seen by anyone outside a small named group and the consequences of leakage are severe, PDF password encryption is not a substitute for controlling distribution through an access-controlled system with logging, because a PDF password can be shared, forwarded, or cracked given enough time and no PDF viewer enforces any kind of expiry or revocation once a file has left your control. Use PDF encryption for protecting a file in transit or at rest against casual access, not as the sole control for content where unauthorized disclosure would be a serious event.