Remove a PDF password

How it works

A PDF can be encrypted and still open without asking anybody for anything. The standard security handler accepts an empty user password: every string and every stream in the document is ciphertext, the key is derived at load time from a password of zero length, and no prompt appears because there is nothing to prompt for. The file is protected against a list of operations rather than against being read.

That shape is the common one, and it follows from what the two passwords are for rather than from any count: an author who wants a document read but not altered sets an owner password and leaves the user password empty, which is exactly the file that opens with no prompt and still refuses to print. So this page tries the empty password before asking anyone for one, and says which of the two situations the file turned out to be in.

The password the reader never sees

A viewer that opened a document on the empty password knows it has not authenticated as its author, and it is never shown the author's password at any point. That second password is another route to the same key rather than a credential the file hands over. What the viewer is given instead is the permission field the author left behind, which is how a document you can read on screen can still decline to print. The companion page on protecting a PDF covers how those passwords are set and what the field holds.

Here the field matters as something to report before it is deleted. The result note names each operation the document was withholding, because a person who has just taken protection off a file is entitled to know what was on it.

What removing it does

Decryption happens on load rather than on save. Given the password, @cantoo/pdf-lib returns a document whose strings and streams are already plaintext in memory, and records the fact on the parsing context as `isDecrypted`. That flag stays false for a document that was never encrypted, so it is also how this page tells an ordinary PDF from one carrying an empty password, and an ordinary PDF is handed straight back rather than rewritten for nothing.

Writing the decrypted document out is a separate step, and on its own it removes nothing. Measured here on 2026-08-06 with a two-page test file: a 1,565-byte permissions-encrypted PDF, loaded with the empty password and saved immediately, came out at 1,586 bytes, and pdf-lib's own reader then refused that output with `EncryptedPDFError`. The handler dictionary survives the round trip as a retained object and the writer puts it straight back. Deleting that object first brought the same document out at 1,439 bytes, and it reopened.

So the output is a document with no security handler, rather than one flagged as no longer protected. There is no encryption dictionary, no permission field, no trailer entry pointing at either, and nothing recording that they were ever there. One more object goes: the original cross-reference stream survives the rebuild unreachable from the new trailer, still carrying the old encryption reference inside itself, and removing it took the same test file from 1,439 bytes to 1,137. Scanning the finished bytes for `/Encrypt` then finds nothing, which matters because that scan is how every other PDF page here decides whether a file is protected.

When the password is refused

A refusal is an answer, so it is returned as one rather than raised as an error. The library separates the two failures precisely: asked to open a protected file with nothing supplied it reports `NEEDS PASSWORD`, and given a password that does not authenticate it reports `Password incorrect`. Both come back as rows on the page. An error would leave the previous file's result sitting on screen under the new file's name, which is the one failure mode worse than saying no.

One behaviour is worth knowing before concluding that a password is wrong. Measured on a file encrypted with a user password of `letmein` and an author password of `owner-secret`, both strings open it: the crypto layer retries a rejected user password as an author password before giving up. A file that refuses both is refusing the password rather than the format.

For a document whose password nobody has, there is nothing here. The key is derived from the password, so without it the only route is trying candidates one at a time, and this page tries exactly one: the empty string, because it costs nothing and answers the common case above.

What does not survive

Taking the handler off means writing every object out again, and a rewrite loses whatever the writer cannot reproduce. A digital signature is the clean example. It certifies a byte range of the file it was applied to, and the rebuilt file has different bytes at different offsets, so the signature stops verifying. That is arithmetic, not damage, and it applies to any program that decrypts a document rather than to this one in particular.

The chain of incremental updates goes the same way, flattened into a single revision, so a file that had been edited four times comes back as one. Objects the parser could not interpret are carried through verbatim rather than understood, which is exactly why the stale cross-reference above had to be removed deliberately. Anything a viewer decided to hide on the strength of the permission field comes back, since there is no longer a field to consult.