How to Encrypt a PDF File: Methods, Standards and Limitations

Table of Contents

1. Why PDF encryption is more than a password prompt
2. Where encryption lives: the Standard Security Handler
3. The algorithm generations: RC4, AES-128 and AES-256
4. PDF 1.x versus PDF 2.0 (ISO 32000-2)
5. User passwords and owner passwords
6. How the keys are derived
7. What is encrypted and what is not
8. What AES-256 actually protects against
9. What AES-256 does not protect against
10. How to encrypt a PDF with the common tools
11. How to check what an encrypted file uses
12. A practical checklist

Why PDF encryption is more than a password prompt

Most people meet PDF encryption as a dialog box. You choose "Require a password to open the document," type something, and the file asks for it next time. Underneath that dialog is a specific, documented cryptographic design. The design determines which passwords exist, how they are checked, which parts of the file are scrambled, and what an attacker with a copy of the file can attempt. If you handle sensitive documents for a legal team, a clinic, an HR function or an IT department, those details matter more than the button you clicked.

This article is a technical explainer. For a step-by-step tutorial on protecting a document on a Mac or in Acrobat, see our guide on how to password protect a PDF and share it securely. Here we focus on the standards, the key handling, and the limitations that follow from them.

Where encryption lives: the Standard Security Handler

A PDF file is made of objects: pages, fonts, images, streams of drawing instructions, dictionaries of metadata. Encryption in the PDF format is handled by a component called a security handler. The handler that almost every password-protected PDF uses is the Standard Security Handler, identified by /Filter /Standard in the file's encryption dictionary, which is referenced from the trailer.

The encryption dictionary carries the parameters that matter. Its main entries are:

• /V, the algorithm version. Values of 1 and 2 correspond to RC4, 4 to the crypt-filter framework used for AES-128, and 5 to AES-256.
• /R, the revision of the handler. Revisions 2 to 4 are associated with RC4 and AES-128, and revisions 5 and 6 with AES-256.
• /O and /U, the owner and user password verification and key-recovery values.
• /P, a 32-bit integer that encodes the permission flags. We cover these in detail in our companion article on PDF permissions.
• /Length, the key length in bits, and /CF, /StmF and /StrF, the crypt filters that say which algorithm applies to streams and strings.
• /EncryptMetadata, a boolean that determines whether the document's XMP metadata stream is encrypted along with everything else.

Because all of this sits in a dictionary the reader must parse before it can decrypt anything, the handler is also the place where an attacker looks first. The encryption dictionary is not itself encrypted, and this is a deliberate design feature. A reader needs it in plain form to know what kind of key to derive.

The algorithm generations: RC4, AES-128 and AES-256

PDF encryption has been updated several times, and it helps to understand the sequence because you will still encounter older files.

RC4 (40-bit and 128-bit). The earliest PDF encryption used the RC4 stream cipher. The 40-bit variant was introduced with PDF 1.1, and 128-bit RC4 arrived with PDF 1.4 and Acrobat 5. RC4 has well-documented statistical weaknesses and is not considered acceptable for new protection. ISO 32000-2 marks RC4 as deprecated. If a file you receive is encrypted with RC4, treat that as a sign that it was produced by an old tool or an old workflow, and re-protect it before sending it on.

AES-128. The Advanced Encryption Standard was adopted as a PDF option with PDF 1.6 and Acrobat 7, using AES in CBC mode with a 128-bit key. AES is specified in NIST FIPS 197, and CBC mode is covered in NIST SP 800-38A. NIST continues to approve AES-128 for protecting data, and no practical attack against AES-128 itself is known. Its weaknesses in PDF are the surrounding key management and password handling, which we discuss below.

AES-256. PDF's AES-256 option was introduced in the Adobe extension to PDF 1.7 and shipped with Acrobat 9. It uses a 256-bit file encryption key and, in its modern form, a more elaborate password-verification process than the earlier revisions. AES-256 is part of PDF 2.0. NIST treats AES-256 as approved as well, and many policies choose it for simplicity, for long-term confidentiality requirements, or because it is the default in current tools. A file encrypted with AES-256 is not automatically more secure than one encrypted with AES-128 if the password is weak. The key size is not the bottleneck in most real-world attacks on PDFs.

PDF 1.x versus PDF 2.0 (ISO 32000-2)

The PDF format was standardized as ISO 32000-1, based on Adobe's PDF 1.7 reference, and then revised as ISO 32000-2, which defines PDF 2.0. The second edition brought several security-relevant changes. Among them, RC4 is deprecated, AES-256 encryption with the newer password-validation algorithm is part of the standard rather than a vendor extension, and the handling of permissions and certain cryptographic functions was tightened.

This matters for two reasons. First, a PDF file does not announce which standard it follows in every case. Many files labelled PDF 1.7 are produced by tools that use the AES-256 extension, and many PDF 2.0 files were written by tools that kept older behaviour for compatibility. Second, interoperability is uneven. An AES-256 file produced by a current tool will open in recent versions of Acrobat, Preview, Chrome and most other mainstream readers, but older readers may refuse it or ask for an update.

When you are choosing settings, prefer AES-256 in a PDF 2.0-capable writer, and check the outcome with a verification tool rather than relying on the label in the dialog.

User passwords and owner passwords

This is the most important distinction in PDF security, and it is often misunderstood. A PDF can carry two different passwords.

The user password, sometimes called the document open password, controls whether a reader can decrypt the file at all. If you do not know it, the viewer will not show the content. In the encryption dictionary, the /U value and the related key material are derived from it.

The owner password controls who may change the security settings. The holder of the owner password can alter the permissions, remove restrictions, or change the passwords themselves. Viewers that respect permissions will refuse to print, copy or edit when the owner has restricted those actions, but they enforce this only as a matter of policy, as we explain in the permissions article.

The consequences are direct. A file with an owner password and no user password opens for anyone, and the restrictions are merely requests that a compliant reader is expected to honour. A file with a user password is unreadable to people who lack it, although anyone who can open it can still see the whole document. A file with both has the strongest arrangement: the user password gates reading, and the owner password gates changes.

For revisions 2 to 4 of the Standard Security Handler, the owner password is used to recover the user password in the /O entry. That design is a historical feature, and it means that whoever knows the owner password can, in principle, recover the document key in those revisions. Good practice is to use a long, unique owner password that you do not share with recipients, because sharing it hands over full control of the file.

How the keys are derived

Passwords are not used directly as encryption keys. The handler derives keys from them, and the way it does so determines how expensive offline guessing is.

For revisions 2 to 4, the key derivation uses MD5. For AES-128 at revision 4, the handler applies MD5 repeatedly, 50 times, to a value built from the password, the owner entry, permissions, file identifier and other fields, and it truncates the result to the key length. This is a fast operation on modern hardware. A short or dictionary-based password recovered from an encrypted PDF of this generation can fall to a GPU-based attack quickly. Hashcat and John the Ripper both include PDF cracking modes for these families of files.

For AES-256 at revisions 5 and 6, the design is more careful but still not what modern password-based key derivation guidance would recommend. Revision 5 uses SHA-256 on the password combined with salt values stored in the file. Revision 6, which is what current tools produce, uses an iterative procedure, often called Algorithm 2.B in ISO 32000-2, that repeatedly hashes with SHA-256, SHA-384 and SHA-512, selecting the hash function according to intermediate values, and uses AES-128 in CBC mode during the process. The iteration count is at least 64 rounds, and the loop continues until a stopping condition is met.

This is a better design than the earlier MD5 approach. It is still an iterated hash rather than a memory-hard function such as scrypt or Argon2. NIST SP 800-132 recommends password-based key derivation functions with a salt and a sufficiently high iteration count, and it discusses the trade-off between the cost imposed on legitimate users and the cost imposed on an attacker. An iterated SHA-2 construction does not make a weak password strong. Its effect is to slow the attacker somewhat, and the password still has to resist a dictionary attack.

The practical lesson is blunt. Whatever the revision, the strength of an encrypted PDF is bounded by the entropy of its user password. A twelve-word passphrase generated at random is protected well. A word followed by a year is not.

What is encrypted and what is not

When a PDF is encrypted with the Standard Security Handler, the handler scrambles strings and stream data. That covers the text of the page contents, embedded images, embedded fonts, form values and many annotations.

Several parts of the file are not encrypted in the same way, and this is where many expectations go wrong.

The encryption dictionary itself is in clear. So are the trailer's file identifiers, which are used to match a file to its key material. The cross-reference structure and the object layout remain visible, so anyone can count pages, see roughly how large each object is, and identify which features are present, such as form fields, embedded files or JavaScript objects, even without decrypting them.

Metadata depends on a setting. If /EncryptMetadata is false, the XMP metadata stream is stored in clear, even though the rest of the file is protected. Some tools default to this behaviour for compatibility reasons. You can check the setting with the verification commands below. We cover metadata in depth in our guide to removing sensitive metadata from a PDF before sharing.

Finally, encryption does not hide the file size or timestamps that the filesystem records, nor does it prevent the sender's email client or cloud storage from keeping copies of the file and its name.

What AES-256 actually protects against

Given a correctly produced AES-256 file and a strong user password, the encryption protects the contents against several realistic threats.

It protects against casual and opportunistic access. A file found on a shared drive, a lost laptop, or an intercepted email attachment reveals its contents only to someone who has the user password. Standard tools will not decrypt it without the password.

It protects against storage-level exposure. A cloud provider's administrator, a backup operator or a third party with access to the storage bucket can read the file's bytes, but the page content and images are scrambled. This is confidentiality at rest, and it complements transport encryption such as TLS, which protects the file in transit but does not persist.

It protects the contents of unopened and unpassworded copies. If the user password is shared only through a separate channel, an interceptor of the file alone obtains ciphertext for the content streams.

It also supports compliance and audit requirements. Many frameworks ask for encryption of sensitive data at rest, and an AES-256 PDF with a documented password policy is a defensible answer in those contexts, provided the key management around it is also sound.

What AES-256 does not protect against

This is the section that matters most to a legal, HR or finance team, and it is the one that vendor marketing tends to skip.

Encryption does not protect a document from the people who can open it. Once the reader has the user password, the viewer decrypts the content into memory and renders it. A recipient can select the text, take a screenshot, photograph the screen, or re-type the content. Encryption is not digital rights management. It does not keep content inside the viewer.

Encryption does not stop a recipient from copying the file. Anyone with the encrypted file and the password can save an unrestricted copy. Even without the password, a recipient who has the file can keep it indefinitely and attempt offline guessing at any time.

Encryption does not protect a weak or shared password. The password is the attack surface. Passwords sent in the same email as the file, reused across many documents, or written on a sticky note offer little protection. Offline cracking tools are optimized for exactly the kinds of passwords people choose.

Encryption does not hide the document's existence, structure or size. An observer who does not know the password can see how many pages a file contains, roughly how large its objects are, and whether it carries forms or attachments. For some documents, the fact that a file exists and its size can be informative.

Encryption does not remove what is inside the file by default. A redacted-looking page that still contains its original text under a black box is still a risk, even in an encrypted wrapper. Encryption protects the bytes; it does not decide which bytes should exist. See our explainer on how to redact a PDF properly for why that distinction is critical.

Encryption does not protect against a compromised endpoint. Malware on the reader's machine can capture decrypted content from memory or from the screen. Encryption protects the file, not the device it is opened on.

Encryption does not, by itself, provide access control over time. A PDF cannot be revoked after it leaves your hands, cannot expire on its own, and cannot notify you when it is opened. If you need those properties, you need a sharing system that controls access on a server, as we discuss in our comparison of password-protected PDFs and secure sharing links.

How to encrypt a PDF with the common tools

The two most useful command-line examples below use qpdf, an open-source tool that reads and writes PDF structure. The first creates an AES-256 file with a user password, an owner password, and printing and modification blocked as a policy setting.

qpdf --encrypt "UserPassword" "OwnerPassword" 256 --print=none --modify=none -- input.pdf protected.pdf

The 256 argument selects 256-bit AES. By default, qpdf writes the PDF 2.0 revision 6 key derivation for this key length. If you need the older revision 5 behaviour for a specific reader, qpdf offers a --force-R5 option, though you should only use that when a real compatibility need exists. For AES-128 instead of AES-256, replace 256 with 128 and add --use-aes=y.

Replace the example passwords with values from a password manager. Do not type them into shell history on a shared machine. Use an environment variable or a prompt-based workflow if your team has one.

In Acrobat Pro, the equivalent is under File, then Protect Using Password, where you can choose the compatibility level and the encryption method, including AES-256. Acrobat lets you set both a document open password and a permissions password. In macOS, the Preview route exists but offers less control over the encryption method and the separate owner password. Check the result afterwards, as described below.

How to check what an encrypted file uses

Verification matters more than the label. The following command, from qpdf, prints the encryption parameters of a file:

qpdf --show-encryption protected.pdf

The output tells you whether the file is encrypted, its key length, and which permissions are set. Look for a 256-bit key and a revision of 6 for current AES-256 output. Check whether the file requires a user password, and whether an owner password is set. Use the same tool to confirm that EncryptMetadata is true if you expect metadata to be protected.

For a deeper look at the encryption dictionary, you can use qpdf's object inspection options or a PDF library such as pikepdf. For a quick, non-technical check, see our PDF encryption checker guide.

If you are auditing a file you did not create, check whether it is encrypted with RC4 or AES-128 before you rely on it. Consider re-protecting it under your own controls.

A practical checklist

Before you rely on PDF encryption for a sensitive document, confirm the following.

1. Use AES-256 with a PDF 2.0-capable writer, and verify the result with a tool rather than the dialog's label.
2. Generate the user password randomly with a password manager, and send it through a channel separate from the file.
3. Set a distinct owner password, and keep it to the sender and the document's custodian.
4. Confirm that EncryptMetadata is true if the XMP stream contains anything sensitive, or remove the metadata before encryption.
5. Assume the recipient can read, copy and screenshot the contents once they have opened the file.
6. Decide in advance how you will handle a password leak, such as a forwarded email. Encryption alone cannot revoke access.
7. For documents that need revocation, expiry or access logs, use a secure sharing system rather than relying on the PDF alone.