Unlock PDF: Remove the Password or Restrictions Offline

How to use the Unlock PDF: Remove the Password or Restrictions Offline

1. Add your PDFDrop one or more PDF files on the box, or choose them from your device. The page reads each file on your device and reports the kind of encryption, whether a password is needed to open it, and what the file does not allow.
2. Enter the password if the file asks for oneA file that needs a password to open shows a password field. Type the password you were given. The user password and the owner password both work, and the page tells you which one it was. A file with only restrictions needs no password.
3. Press Unlock this PDFThe page decrypts every string and stream, writes a new file without any encryption, opens that file again, and checks that it needs no password and has the same number of pages.
4. Download the unlocked copyDownload the file, or all unlocked files as a ZIP. The copy is named after the original with unlocked added. Keep the original if a digital signature on it matters, because the copy is a new file.

Two kinds of locked: a password to open, and restrictions

The PDF standard describes two passwords for one file. The user password is the one a reader has to supply to open the document. The owner password is the one that gives full access, including the right to change the restrictions. A file can have an owner password and an empty user password. Everyone then opens it without typing anything, and a viewer that follows the rules disables the operations the owner switched off. This is why you can often read a PDF and still not print it, copy a paragraph, or fill in a field.

The qpdf documentation explains why the second kind of lock is weak. The password only protects a single encryption key, and either password can recover that key. A program that can read the file at all therefore has the key, and the documentation says the restrictions are enforced only by the software that reads the file, so any open source reader could be changed to ignore them. For a file with no open password, this page is that kind of program: it reads the file, which it can because the empty password opens it, and writes it again without the restrictions.

A file that needs a password to open is a different case. Without a password there is no way to the key, and this page does not try to find one. If you have the password, you can use it here. If you do not, the person or system that made the file is the one who can help.

What the page shows before it changes anything

Every encrypted PDF carries an Encrypt entry that names the security handler, its version and revision, the key length, and a permissions number. The page reads that entry and turns it into plain words: RC4 or AES, 40, 128, or 256 bits, whether a password is needed, and the list of things that are not allowed. The permission bits are the ones in the standard: printing, changing the document, copying text and pictures, adding or changing comments and form fields, filling in forms, extracting text for accessibility, assembling pages, and printing in high quality. The oldest revision only defines the first four, so the page lists only those for such a file instead of guessing.

The method matters for how much a password is worth. The qpdf documentation says a 40-bit key can easily be found by brute force whatever the password is, that RC4 is also known to be insecure, and that AES with a 256-bit key is the only secure choice. PDF 2.0, the standard published as ISO 32000-2, deprecates the weak schemes and encourages only AES-256. Seeing the method on this page tells you whether the protection on a file was ever meant to hold.

How the unlocked file is made

In an encrypted PDF only strings and streams are encrypted. Each one has its own key, made from the main key and the number of the object it belongs to, so the page works through the file object by object. It supports the standard security handler in all its forms: RC4 with 40 or 128 bits, AES with a 128-bit key in CBC mode, and AES with a 256-bit key, including the newer password hash that the later PDF 2.0 revision uses. It also honors the setting that leaves the metadata stream unencrypted and the crypt filters that mark some streams as not encrypted.

The page then writes every object it reached, without the Encrypt entry, into a new file with a single cross-reference table. It reads that file back and refuses to offer it unless it opens without a password and has the same number of pages. The pictures, fonts, page content, comments, and attachments are copied exactly as they were decrypted. Files with compressed object streams, files with damaged indexes, and files that were saved several times are handled by the same reader the metadata cleaner on this site uses.

Passwords, alphabets, and the owner password

Older PDF encryption (revision 4 and earlier) uses the password as bytes in a single-byte alphabet, and readers differ on how they convert a typed password. This page uses Latin-1, so a password such as pässwörd works, and it tells you plainly when a password has characters outside Latin-1 that the old methods cannot express. The 256-bit encryption in revision 6 uses Unicode text prepared with SASLprep, so a password with symbols such as the euro sign works there.

If the password you give is the owner password, the page says so, and the result has no restrictions. If it is the user password, the result is also fully unlocked, because the new file has no encryption at all. For a file that opens without a password, an empty field is correct and the page works out the rest.

How the unlocker was tested

Sample files were encrypted with qpdf through pikepdf, which are not part of this page. The 15 files cover 40-bit RC4, 128-bit RC4, AES with a 128-bit key, and AES with a 256-bit key, files with a user password and an owner password, a Latin-1 password, a Unicode password, object streams, a plain metadata stream, and a file with every permission granted. Each file was unlocked with both passwords. Every stream in the result was compared, by SHA-256, with the same stream decrypted by qpdf, and all of them were identical. PyMuPDF opened the results, found the same text, and rendered all 30 pages, two per file, to pixels that were identical to the pages of the originals.

Wrong passwords, a missing password, and a password in the wrong alphabet were checked to be told apart and reported clearly. The AES and RC4 code was also compared with the crypto library of the Node.js runtime on random keys and lengths, and with published test vectors. A last test damaged the encrypted samples in 200 random ways, such as flipped bytes, cut-off files, and a bad index. Each file was either unlocked or refused with a clear message.

Limits and accuracy

• The page does not crack or guess passwords. A file that needs a password to open can only be unlocked with that password.
• A digital signature on the original shows as invalid on the unlocked copy, because the copy is a new file. The page warns you when a file is signed.
• If the file has usage rights or certification data, the page keeps them, but a program may report that they no longer match the unlocked file.
• For files made with revision 4 or older, a password with characters outside Latin-1 cannot be used, because those methods have no defined way to read it.
• Encryption based on a certificate or on a security handler other than the standard password handler is refused with a message.
• The older Adobe Extension Level 3 variant of 256-bit encryption (revision 5) is implemented from the specification, but it was not tested, because no tool used for the tests can create such a file.
• Only unlock files you own or have the right to open. Restrictions are often set by the author for a reason, and lifting them does not change who holds the rights to the content.
• A damaged file that cannot be read is refused instead of being guessed at, and your original is never changed.

Frequently asked questions