How to Encrypt and Password-Protect PDF Files

By Michael Peters · Published March 17, 2026 · Last updated March 24, 2026 · 5 min read

← Back to Blog

Two Types of PDF Password

Adobe Acrobat supports two distinct password types for PDF security, and understanding the difference between them is essential before applying protection to a document. For a broader overview of how PDF security works at the specification level, see our article on PDF security.

Document Open Password (also called a User Password): This password must be entered before the PDF can be opened at all. Without it, a viewer cannot read the document. This is the appropriate protection when you need to restrict who can access the content — for example, when distributing a confidential report to a limited audience.

Permissions Password (also called an Owner Password or Master Password): This password controls what an authorised viewer can do with the document after opening it. It governs actions such as printing, copying text, editing, and form completion. A document protected with only a Permissions Password can be opened without any password, but the restricted operations are prevented in conforming PDF viewers. The Permissions Password is required to change or remove those restrictions.

You can apply either password independently, or both together. If both are set, the Document Open Password must be entered to view the file, and the Permissions Password is required to change the security settings.

You can also password-protect PDFs or unlock password-protected PDFs online for free using Mapsoft's PDF Hub — no installation required.

Encryption Algorithms

PDF encryption strength is determined by the encryption algorithm selected when security is applied:

• RC4 40-bit (Acrobat 3 and later compatibility): Legacy encryption, now considered cryptographically weak. Should not be used for documents requiring genuine security.
• RC4 128-bit (Acrobat 5 and later compatibility): Stronger than 40-bit RC4 but RC4 itself is a deprecated cipher. Acceptable only for legacy compatibility requirements.
• AES 128-bit (Acrobat 7 and later compatibility): AES (Advanced Encryption Standard) is the current standard cipher. 128-bit AES provides strong security for most practical purposes.
• AES 256-bit (Acrobat X and later compatibility): The strongest available option in Acrobat. Required for high-security applications and recommended for all new documents where compatibility with older versions of Acrobat is not a constraint.

For new documents, always choose AES 256-bit unless recipients are known to be using Acrobat 9 or older.

Setting Passwords in Adobe Acrobat

1. Open the PDF in Adobe Acrobat Pro.
2. Go to File > Properties and click the Security tab, or go to Tools > Protect > Protect Using Password.
3. In the Document Properties > Security tab, select Password Security from the Security Method dropdown and click Change Settings.
4. In the Password Security Settings dialog, choose your compatibility level (which determines the encryption algorithm).
5. To require a password to open the document, tick Require a password to open the document and enter the Document Open Password.
6. To restrict permissions, tick Restrict editing and printing of the document and enter the Permissions Password. Then configure the individual permission flags (see below).
7. Click OK, confirm each password when prompted, and save the document. The security settings take effect after saving.

Permission Flags

When applying a Permissions Password, you can configure the following restrictions:

• Printing: Allow no printing, low-resolution printing only, or full high-resolution printing.
• Changes: Prevent all editing; allow only form filling and signing; allow commenting and form filling; or allow all editing except page extraction.
• Content copying: Prevent text and image content from being copied to the clipboard.
• Accessibility: A separate flag allows screen readers and accessibility tools to access the content even when copying is otherwise restricted.

Note that permission flags are honoured by conforming viewers such as Adobe Acrobat Reader, but are not enforced by all third-party PDF tools. Permission restrictions are a deterrent for casual misuse; they are not a technical barrier against determined extraction using non-conforming software.

Certificate-Based Security

As an alternative to password protection, Acrobat supports certificate-based security, where encryption keys are tied to digital certificates rather than shared passwords. This approach is more secure in multi-recipient workflows — each authorised recipient uses their own private key to decrypt the document, eliminating the need to share a common password. Certificate security requires each recipient to have a digital certificate available to Acrobat and is more appropriate in enterprise environments with existing PKI (Public Key Infrastructure) infrastructure.

Removing Password Protection

If you hold the Permissions Password for a protected document, you can remove security via File > Properties > Security, change the Security Method to No Security, enter the Permissions Password when prompted, and save the file. The Document Open Password, if set, can also be removed this way once you have authenticated.

Without the correct password, removing PDF security through legitimate means is not possible. Third-party password recovery tools exist but are outside the scope of normal document workflows.

Limitations: What PDF Encryption Cannot Prevent

PDF encryption protects the file contents while the file is at rest and in transit. It does not prevent a person who has legitimately opened the document from taking a screenshot of the screen, photographing the screen, or manually transcribing the content. For truly sensitive material, PDF encryption is one layer of a broader security approach — not a complete solution in isolation.

Programmatic Password Protection

PDF encryption can be applied programmatically using server-side PDF libraries such as iText (Java/.NET), PDFBox (Java), or Aspose.PDF. This is the standard approach for workflows where PDFs must be encrypted at the point of generation — for example, automatically encrypting invoice PDFs before emailing them, or securing generated reports in a document management system. For digital signature-based authentication as an alternative to passwords, see our guide on PDF digital signatures.

For batch encryption within Adobe Acrobat, Mapsoft’s SecuritySetter plugin lets you apply password protection, permission restrictions, and encryption settings across multiple PDF files in a single operation — ideal for organisations that need to secure large document collections without processing each file individually.

Regulatory Context: HIPAA, GDPR, PCI-DSS, and SOC 2

Most PDF encryption isn’t deployed for fun — it’s deployed because a regulator, contract, or compliance standard requires it. Understanding what each framework actually mandates helps you pick the right encryption strategy rather than over- or under-protecting documents.

HIPAA (US Healthcare)

HIPAA’s Security Rule requires covered entities and business associates to encrypt electronic protected health information (ePHI) "at rest" and "in transit", but doesn’t specify a particular algorithm. NIST SP 800-111 (the de-facto reference) recommends AES with 128-bit minimum, 256-bit preferred. PDF AES 256-bit (Acrobat X compatibility level) satisfies HIPAA’s technical requirements when combined with appropriate administrative safeguards (access logging, employee training, business associate agreements). What HIPAA does not require is password protection on every PDF — encryption at the storage layer (the database, the document management system) is sufficient if implemented correctly.

GDPR (EU and UK)

GDPR Article 32 requires "appropriate technical and organisational measures" including encryption "where appropriate". Unlike HIPAA, GDPR doesn’t mandate encryption universally — it requires a risk-proportionate approach. The practical interpretation: PDFs containing personal data of EU/UK data subjects should be encrypted when emailed, stored on portable media, or transmitted through systems where unauthorised access is plausible. AES 256-bit is the safe default. Note that GDPR’s data-residency rules apply to encrypted PDFs as well as unencrypted ones — encryption doesn’t exempt you from keeping EU data within EU borders.

PCI-DSS (Payment Card Industry)

PCI-DSS Requirement 3.4 requires "strong cryptography" for the storage of cardholder data, which the standard defines as AES with 128-bit minimum or RSA with 2048-bit minimum. Documents containing primary account numbers (PANs), card validation codes, or full magnetic stripe data must be encrypted at rest. PDF AES 256-bit comfortably meets the standard. PCI-DSS additionally requires documented key management practices — how passwords are generated, distributed, rotated, and retired — which often gets overlooked when teams focus only on the encryption algorithm.

SOC 2 and ISO 27001

SOC 2 (a US audit framework) and ISO 27001 (the international information security management standard) don’t prescribe specific encryption algorithms but require risk-based controls that almost always include encryption of sensitive data. For SOC 2 Type II audits and ISO 27001 certification, you’ll need documented policies stating what gets encrypted, how (algorithm, key strength), by whom (responsible roles), and when (at generation, before transmission, on archival). Auditors check the documentation against actual practice, so consistency matters more than choosing the strongest possible algorithm.

Batch Encryption Scripts

For workflows where individual files need encryption applied at scale — outbound invoices, monthly statements, regulatory archives — manual encryption in Acrobat doesn’t scale beyond a handful of files. Three production patterns:

Acrobat Action Wizard with Encryption Step

Build an action that includes an "Encrypt" step configured with your standard password and security settings, then point it at a folder. The action processes every file in the folder, encrypting each one with the same settings. Right for moderate volumes (tens to hundreds of files per run) where the encryption parameters are uniform.

iText (Java/.NET) Batch Script

For genuinely high volumes or workflows where the encryption parameters vary per file (different passwords per recipient, for example), a server-side library is the right tool. iText is the standard:

// iText 7 (Java) example - encrypting a folder of PDFs
import com.itextpdf.kernel.pdf.*;

public static void encryptPdf(String src, String dst, String userPwd, String ownerPwd) {
    WriterProperties props = new WriterProperties()
        .setStandardEncryption(
            userPwd.getBytes(),
            ownerPwd.getBytes(),
            EncryptionConstants.ALLOW_PRINTING,  // permissions flags
            EncryptionConstants.ENCRYPTION_AES_256
        );
    PdfReader reader = new PdfReader(src);
    PdfWriter writer = new PdfWriter(dst, props);
    new PdfDocument(reader, writer).close();
}

Aspose.PDF and PDFBox offer equivalent APIs. The Adobe PDF Services API exposes encryption as a managed cloud operation — covered in our Adobe PDF Services API post — for teams that prefer not to run their own infrastructure.

Per-Recipient Password Generation

For workflows where each recipient needs their own password (financial statements, payslips, personalised reports), the encryption pipeline needs to generate or look up a password per file and securely communicate it to the recipient through a separate channel. The pattern: a master CSV of recipient identifiers and passwords, an encryption script that reads the CSV and applies the right password per file, and a delivery system that emails the encrypted PDF and SMS-es or otherwise out-of-band-delivers the password. The crucial discipline is never sending the password through the same channel as the PDF — if the email is intercepted, an inline password defeats the encryption.

Common Encryption Mistakes

Five recurring mistakes that defeat PDF encryption in practice:

• Weak passwords. AES 256-bit encryption with the password "Password123" is no stronger than its weakest password against a brute-force attack. Generate passwords algorithmically (16+ random characters) and use a password manager rather than human-memorable strings.
• Sending password and PDF together. An encrypted PDF emailed alongside its password in the same message provides no protection. Use a separate channel for the password — SMS, phone call, password-manager share link, or out-of-band system.
• Forgetting the owner password. Without the owner password you cannot remove the security later. Lost owner passwords mean re-creating the source document, which for archival material may be impossible. Document your owner passwords in a secure password manager with appropriate access controls.
• Relying on permission flags alone. Permission flags are honoured by conforming viewers but ignored by some third-party tools and by anyone determined enough to use specialised software. Treat permission flags as a deterrent, not a security boundary — for material that genuinely must not be printed or copied, encrypt with a Document Open Password as well.
• Using deprecated RC4. RC4 40-bit is cryptographically broken; RC4 128-bit relies on a deprecated cipher with known weaknesses. Always use AES 128-bit or 256-bit unless an explicit legacy compatibility requirement forces otherwise.