Password-Protected Sample PDF (Password: test123)
Two encrypted samples with nothing to guess: sample-password-protected.pdf refuses to open until you supply test123, and sample-permissions-restricted.pdf opens without any password but arrives with printing, copying and editing restricted. Between them they cover both kinds of "locked PDF" your code will meet.
The two kinds of PDF protection
PDFs have two separate passwords, and conflating them causes endless confusion. The user password (open password) encrypts the document — without it, nothing can read the contents, and any tool must show a password prompt. The owner password doesn't stop the file opening; it encrypts the file but grants everyone a no-password read, while asking viewers to honor restriction flags: no printing, no copying, no editing. Crucially, those flags are requests — a compliant viewer greys out the Print button, but the content itself is readable by design.
sample-password-protected.pdf has both passwords set (user test123,
owner owner123). sample-permissions-restricted.pdf has only an
owner password — that's the one that surprises people, because it "isn't locked" until they
try to copy a paragraph.
What to test
- The password prompt path — drop the protected file into the viewer or lock / unlock: you should be asked for a password, and
test123should work. A tool that errors with "corrupt file" instead of asking is mishandlingPasswordException. - The wrong-password path — try
wrong123first, then the real one. Plenty of tools handle the first prompt but crash on retry. - Removing protection — unlock it with the password, save, reopen: no prompt should appear. That's the legitimate "I know the password, I'm tired of typing it" workflow.
- Permission flags — open the permissions-restricted file and check whether your viewer actually greys out print/copy, and whether your library surfaces the flags (pdf.js:
getPermissions()). - Batch-tool behavior — feed the protected file to a merge along with normal files: the correct behavior is a per-file error naming the locked file, not a batch-wide crash.
A note on "cracking" PDFs
These samples exist so you can test flows where the password is known. Removing a user password you don't know isn't a testing scenario, and modern PDF encryption (AES-256) holds up; tools promising otherwise are guessing weak passwords at best. If you've genuinely lost a password to your own document, the honest options are your password manager, the person who sent it, or the source system that generated it.
FAQ
What encryption do the samples use?
AES-256 via the pdf-lib encryption fork used in our open-source generator. The /Encrypt dictionary is verified as part of the build — the generator fails if encryption silently didn't apply.
Why would anyone publish the password?
Because the file is for testing password flows, not secrecy. You need a file where the prompt appears and a known-good password exists — otherwise you can't write the happy-path test.
The restricted file opens without a password — is it broken?
No, that's the point of the second sample: owner-password-only files open freely but carry restriction flags. If it opened and let you copy text without complaint, your viewer ignores permission flags (many do — that's worth knowing about your stack).
Can I re-protect a PDF with my own password?
Yes — the lock / unlock tool adds a password to any PDF, right in the browser; the file never leaves your machine.