PDF Password

PDF Encryption: What It Protects (and Doesn't)

PDF supports two distinct security mechanisms that often get conflated: encryption (file content scrambled, requires a password to read) and permissions (file readable but actions like printing/copying restricted via a flag). These have different threat models, different cryptographic strengths, and different ways to remove them. This tool handles both, with different operations.

Encryption vs Permissions

Encryption (user password). The file content is encrypted with a key derived from the password. Without the password, the file is bytes of noise; viewers display an error. To unlock, you must know the password, there's no shortcut. The PDF Password tool removes this only if you provide the password (it decrypts, then re-saves without encryption).

Permissions (owner password). The file content is NOT encrypted. Anyone can open it. But the file declares "printing not allowed, copying not allowed, editing not allowed" in metadata flags. Compliant viewers (Adobe Acrobat) refuse those actions unless the owner password is entered. The tool removes these flags without needing the owner password, the file is already openable, so a clean re-save without the permissions block works.

This is why "remove restrictions" works on most "protected" PDFs without needing a password: the restrictions are advisory, not cryptographic.

Encryption Algorithms Across PDF Versions

If you're encrypting a sensitive PDF in 2026, use AES-256 (PDF 2.0 or 1.7 with Adobe extensions) with a long random password. Anything less is theater.

Stripping Permissions: Why It Works Without the Password

The PDF spec specifies how viewers should respect permission flags. It does NOT require the file to be cryptographically locked against re-saving without those flags. A viewer that respects permissions is voluntary compliance with the document author's wishes.

This means: any tool that can parse and rewrite a PDF can strip the permissions. pdf-lib, qpdf, Ghostscript, Adobe Acrobat (with the owner password, though some scripts work around this), all can produce a clean copy without restrictions.

This is by design: the PDF spec wants documents to be widely readable. The permission system is for "polite" restriction (signal intent to readers), not strong DRM.

For real document protection, use:

• User password (encryption), actually blocks reading.
• Watermarks, visual identification of the recipient.
• DRM-protected formats, specific products (Adobe DRM, ePub3 DRM) that add cryptographic enforcement.

When Permission Restrictions Cause Real Problems

• Accessibility. A blind user with a screen reader can't read the PDF if "copy/extract" is disabled (the screen reader extracts text). Stripping the restriction enables the screen reader. Most jurisdictions allow this under accessibility exceptions.
• Archival. A research paper with copy disabled can't be quoted or transcribed for legitimate citation.
• Workflow. Internal documents with overly restrictive flags (printing disabled on a doc you need to print) annoy more than they protect.

Cracking Unknown Passwords (For Reference)

This tool doesn't do this, but for completeness: tools that brute-force PDF passwords exist:

• John the Ripper with PDF support.
• hashcat with mode 10500 (PDF 1.4-1.6) or 10700 (PDF 1.7 AES).

Strategy: dictionary attacks first (common passwords, leaked password lists), then masked attacks (you remember the structure: "starts with [Name], ends with year"), then brute-force (last resort). Time scales exponentially with password length and entropy:

• 8 characters lowercase + digits: hours on a GPU.
• 10 characters mixed case + digits + symbols: weeks to months.
• 12+ characters random: practically infeasible.

If you legitimately need to recover access to an encrypted PDF you own, these tools work, but plan for time and computational cost.

Password Best Practices When You Encrypt

If you're the one ADDING encryption to a PDF (this tool removes, but the principles inform decisions):

• Length over complexity. A 16-character passphrase (correct horse battery staple) is much stronger than an 8-character mixed-case password and easier to remember.
• Don't reuse passwords across documents. If one leaks, all are exposed.
• Communicate the password out-of-band. Email the PDF, text the password (or use a password manager's secure note feature). Don't send password in the email body.
• Plan for password loss. If you'll need the document in 5 years, store the password in your password manager, not a sticky note.
• For multi-recipient docs, encryption with shared passwords is brittle. Consider per-recipient links via a secure portal instead.

Legitimate Uses of This Tool

• Documents you own where you forgot the restrictions were applied.
• Documents you authored that you want to re-share without the restrictions.
• Accessibility workflows where the restrictions block screen readers.
• Archival/research when documents you have legitimate rights to need to be transcribed.
• Migration from a tool that applied permissions to a new workflow that doesn't need them.

Privacy

pdf-lib runs entirely in your browser. The password (when you provide one) is used in-memory to derive the decryption key; the key and password are discarded when you close the tab. The PDF is read via FileReader, decrypted/modified in JavaScript memory, and downloaded as a Blob. Open DevTools Network during use: zero outbound requests. The password never reaches a server; the file never leaves your machine.