PDF Security Explained: Passwords, Permissions, and Encryption

PDF security is a set of optional controls defined by the PDF specification that a document author can apply to a file. There are three independent mechanisms, often used together:

• Password to open — the document is encrypted and cannot be viewed without the correct password.
• Permissions — a set of flags that restrict printing, copying, modification, and other actions, even after the document is opened.
• Encryption — the algorithm and key length used to scramble the document's content so it is unreadable without the key.

These are defined in the PDF standard's Standard Security Handler. A PDF with none of these applied is an ordinary unsecured document — fully readable and editable by anyone who can open it.

A secured PDF can have two distinct passwords, and understanding the difference matters:

• User password (also called the "open password"). Required to open and view the document. Without it, the file cannot be decrypted at all.
• Owner password (also called the "permissions password"). Required to change the permission flags — for example, to remove the print restriction or allow copying. A reader who has only the user password can open the file but is bound by the permissions the owner set.

A document can have a user password, an owner password, or both. A common pattern is to set only an owner password: the document opens freely for anyone, but actions like printing or copying are restricted unless the reader supplies the owner password. Setting only a user password means anyone who can open the file also has full permissions — the password gates access, not behavior.

Permissions are stored as a 32-bit integer in the security handler. Each bit corresponds to a specific action. The most commonly used permission flags are:

• Print — whether the document can be printed at all.
• Print high resolution — separate from basic print; some documents allow low-quality printing but not high-fidelity output.
• Copy or extract text and graphics — whether content can be copied to the clipboard or extracted by accessibility tools.
• Modify contents — whether the page content can be edited.
• Annotate, fill forms, and sign — whether comments, form fields, or digital signatures can be added.
• Assemble — whether pages can be inserted, removed, or rotated.
• Extract for accessibility — a separate flag that permits text extraction specifically for screen readers and assistive technology.

These flags are enforced by the PDF viewer, not by the file itself. A compliant reader honors them; a non-compliant tool may ignore them entirely. This is a critical limitation discussed below.

The encryption algorithm and key length determine how hard the document is to crack by brute force. The PDF standard has supported several over its history:

• RC4 (40-bit and 128-bit) — the original PDF encryption algorithm. 40-bit RC4 is weak by modern standards and considered deprecated. 128-bit RC4 is stronger but RC4 itself has known cryptographic weaknesses and is no longer recommended.
• AES-128 — introduced in PDF 1.6. A modern block cipher with a 128-bit key. Significantly stronger than RC4 and widely supported by current PDF readers.
• AES-256 — introduced in PDF 1.7 Extension Level 3 and carried into PDF 2.0 (ISO 32000-2). The strongest option in the standard. Note: some early AES-256 implementations had a flaw where the password hash could be attacked independently of the document, weakening protection — modern writers use the corrected revision.

For new documents, AES-256 is the recommended choice where available. RC4 should be avoided. The encryption applies to the document's strings and streams (the actual content), not to the file's structural skeleton — object numbers and the cross-reference table remain visible so readers can navigate the file without the key.

When a writer encrypts a PDF, it derives an encryption key from the user password using a hashing scheme defined by the security handler revision. That key is used to encrypt the document's string and stream objects. The permission flags and a verification hash are stored in the document's encryption dictionary, which itself is not encrypted (so a reader can detect that the file is secured and prompt for a password).

When a reader opens the file, it uses the supplied password to re-derive the key, checks it against the stored hash, and — if valid — decrypts each object on demand. Permissions are checked by the viewer before allowing each restricted action. Because the structure is not encrypted, a secured PDF still reveals file size, page count, and the presence of encryption, but not the page contents.

PDF security is useful, but it is important to understand what it is not:

• It is not DRM. PDF security does not tie the document to a specific device, user account, or license server. Anyone with the user password can open the file anywhere and pass it along.
• Permissions are advisory, not enforced. Because the viewer enforces permission flags, a tool that chooses to ignore them can copy, print, or extract content regardless. Several open-source PDF libraries and some readers do exactly this. Permissions deter casual users; they do not stop a determined one.
• Passwords can be brute-forced. A weak user password on an AES-encrypted PDF can be recovered by offline dictionary or brute-force attacks at speeds of millions of guesses per second on modern hardware. Encryption strength does not compensate for a weak password.
• Older encryption is breakable. 40-bit RC4 can be cracked in seconds. 128-bit RC4 has structural weaknesses. Documents encrypted with these legacy settings offer very little real protection today.

The practical takeaway: use a strong, long user password and AES-256 encryption when real confidentiality is needed. Treat permission flags as a convenience, not a security boundary.

IXPDF is built on a local-first, privacy-first architecture: your files never leave your device. That commitment applies equally to a future protect or unlock feature — the encryption or decryption would happen in your browser, not on a server.

However, IXPDF does not currently offerpassword protection orpassword removal tools. Both are marked Research Required. The reason is technical: our current PDF engine, pdf-lib, does not support reading or writing encrypted PDFs. Adding reliable PDF encryption requires a different engine that we have not yet evaluated for bundle size, performance, and browser compatibility — and we will not ship a feature that does not meet our quality bar. When a suitable engine is integrated, these tools will become available while keeping all processing local.

In the meantime, the concepts on this page still apply to any PDF you encounter. To check what a file's metadata reveals without uploading it, see ourmetadata reference and the localedit metadata tool.