How PDF encryption really works — and its limits

SpecSpec: ISO 32000-2, §7.6ISO 32000-2 §7.6

At a glance

PDF encryption scrambles the words and images inside a document so that only someone with the right password can read them. It is genuine cryptography, and it is good at the one job it has. It is also widely misunderstood, because the same feature carries a second mechanism — permission flags — that looks like a lock and is not one.

This page separates the two. It explains what AES-256 actually protects, what the two passwords are really for, and where the honest boundary sits.

Why this matters

People reach for encryption when a document is sensitive: a contract, a payslip, a medical letter. The expectation is reasonable — keep this private, and stop people from printing or copying it. PDF delivers the first half of that wish convincingly and the second half only on the honour system.

Confusing the two is where the cost lands. A team marks a file “no copying”, trusts that the platform enforces it, and ships. Months later someone copies the text in thirty seconds with a different reader, and the assumption that never held quietly turns into a leak. The encryption was never broken. It was simply asked to do something it does not do.

The short version

• Encryption protects confidentiality. With AES-256, the string and stream content of a PDF is real ciphertext. Without the key, it is unreadable.
• The user password opens the document. Supply it and you can see the content. Without it, there is nothing to read.
• The owner password governs permissions. It is the “full rights” key. The permission flags it guards — print, copy, modify — are recorded inside the encrypted document.
• Permission flags are reader-cooperative. They are a request to a well-behaved reader, not enforcement. A reader that ignores them can print, copy, or edit anyway.
• The structure stays visible. Encryption hides content, not the document’s skeleton — page count and object layout are not the secret.

How NextPDF approaches it

PDF encryption is defined by SpecSpec: ISO 32000-2, §7.6ISO 32000-2 §7.6. The model is precise: a security handler derives a file encryption key from a password, the document’s strings and streams are encrypted with that key, and an encryption dictionary — referenced from the file trailer — records which cipher was used, how long the key is, and which permissions the author declared.

The modern, recommended cipher is AES with a 256-bit key. When you encrypt a PDF this way, the readable payload — the text you would extract, the image bytes, the font data — is transformed into ciphertext. The document’s outer shape stays legible by design: a reader has to find the encryption dictionary and learn the key length before it can ask you for a password. That is why encryption is best understood as content confidentiality, not whole-file opacity.

The two passwords sit at different layers, and the distinction is the part most worth getting right.

1. A password is suppliedEither the user password (open) or the owner password (full rights).
2. The security handler derives the keyISO 32000-2 §7.6.4 turns the password into the file encryption key.
3. Content is decryptedAES-256 turns the encrypted strings and streams back into readable bytes.
4. Permissions are consultedThe owner key grants all rights; the user key is bound by the declared permission flags — if the reader chooses to honour them.

How a password becomes readable content: the user password (or the owner password) is run through the standard security handler's key-derivation routine to recover the file encryption key, which then decrypts the document's strings and streams. The owner password additionally unlocks the full set of permissions; the user password is bound by whatever permission flags the author declared.

The user password is the open password. It answers one question: may you see the content at all? No user password, no readable document — that part is cryptographically enforced, because without the derived key there is nothing to decrypt.

The owner password is the permissions password. A file can be opened by anyone (no user password) yet still declare an owner password that gates the “full rights” actions — printing at high resolution, copying text, modifying the file. Crucially, the permission bits the owner password protects are integrity-protected by the standard security handler: tampering with them is detected and rejected by a conforming reader, because the handler binds the declared permissions to the encryption keys. The bits are not literally unreadable or uneditable bytes — an attacker can change them — but an altered copy will not validate, so a conforming reader treats it as corrupt. They are tamper-evident. They are simply not self-enforcing.

Human-factors note:Human-factors note

The honest mental model is a sealed envelope with a note on the letter inside. The envelope (encryption) genuinely keeps strangers out — only the key opens it. The note (“please don’t photocopy this”) is real, it is sealed so a forged copy is detectable, and a courteous reader will obey it. But the note has no hands. Once a reader is inside, nothing in the paper itself can stop a copy. Treat the envelope as security and the note as etiquette, and you will never be surprised.

Practical example

Encryption settings are simple to express. What matters is reading the result honestly: this configures intent, and the permission portion of that intent is advisory.

<?php

declare(strict_types=1);

use NextPDF\Core\Document;
use NextPDF\Security\Encryption\EncryptionMode;
use NextPDF\Security\Encryption\Permission;

$document = Document::createStandalone();
$document->setTitle('Confidential Offer');
$document->addPage();

// Confidentiality is real: AES-256 means the content is unreadable
// without the user password. This half is cryptographically enforced.
$document->encrypt(
    userPassword: 'open-sesame',
    ownerPassword: 'full-rights-key',
    mode: EncryptionMode::Aes256,
    // Permissions are a declared request to a cooperating reader,
    // recorded inside the encrypted document — not a hard lock.
    permissions: Permission::Print->value | Permission::CopyContent->value,
);

$document->save('offer.pdf');

The user and owner passwords are different keys with different jobs. The permissions argument states what a well-behaved reader should allow. It is honest metadata, integrity-protected by the security handler so that tampering is detectable — and that is the ceiling of what a producing library can promise.

Common misconception

The trap is reading “permissions” as “enforcement”. It is intuitive: the flag says printing not allowed, so surely printing is blocked. But nothing in the PDF can reach out and disable a reader’s print button. The permission integer is recorded for a cooperating reader to honour. A reader that chooses not to cooperate — and several do not — is free to print, copy, and edit.

NextPDF is deliberate about this. The core encryption path treats the permission flags as declared intent and never pretends to enforce them. If you need actions to be genuinely prevented, that control has to live outside the file — in who you give the document to, or in an access-control system around it.

Limits and boundaries

Be precise about what each half guarantees. Encryption (the user-password layer) is a real confidentiality control: strong if the password is strong, and only as good as the secret you choose. Permissions (the owner-password layer) are tamper-evident metadata, not access control.

What you might expect	What encryption actually delivers
Nobody can read the content without the password	True. With AES-256 and a strong user password, the strings and streams are unreadable without the key. Genuinely enforced.
Nobody can rewrite “no copying” into “copying allowed”	Tamper-evident, not impossible. The permission flags are integrity-protected by the standard security handler: an outsider can edit the bytes, but the altered copy will not validate, so a conforming reader detects and rejects the change.
The reader will be prevented from copying or printing	Not guaranteed by any PDF producer. A non-cooperative reader can ignore the flags. This is a property of the format, not a NextPDF limitation.

Two further boundaries are worth stating plainly. First, encryption protects content, not the document’s structure: object layout and page count remain visible, which is normal and necessary for a reader to locate the encryption dictionary. Second, an encrypted PDF cannot also claim archival PDF/A conformance — that profile forbids the Encrypt entry, so you choose one or the other. The encryption-and-permissions troubleshooting page covers the specific exceptions and the PDF/A refusal in detail.

Related docs

• The standards landscape — where ISO 32000-2 and its encryption clauses sit among the PDF standards.
• Encryption and permission flags — the practical entries: decryption failures, and the permission boundary in code.
• What a PDF actually is — the object model that encryption protects, and the structure it leaves visible.
• How signatures sit in a PDF — the other half of document trust: encryption hides, signatures prove.

Glossary

• AES-256 — the Advanced Encryption Standard with a 256-bit key, the recommended modern cipher for PDF content encryption.
• User password (open password) — the secret required to open and read an encrypted document. Without it, the content cannot be decrypted.
• Owner password (permissions password) — the “full rights” secret that governs the permission flags. A document can have one without requiring a user password to open.
• Permission flags — the declared print/copy/modify intent stored in the encryption dictionary. Integrity-protected so tampering is detectable, but honoured only by a cooperating reader.
• Security handler — the component that derives the file encryption key from a password, defined by the standard security handler in ISO 32000-2.
• Reader-cooperative — a control that depends on the consuming software choosing to obey it, rather than being enforced by the file itself.