PDF

PDF Won't Accept the Correct Password: Diagnosis and Fixes

You have the password, you typed it carefully, the PDF still rejects it. This is almost always a clipboard or encoding issue rather than a real password mismatch — the file is fine, the password is fine, but something between the two is wrong. The fixes below work through the most common causes in order, ending with the rare case of a damaged encryption dictionary.

Quick fix

  1. Type the password manually instead of pasting it. Pasted passwords often pick up trailing whitespace, smart quotes, or invisible formatting characters from the source.
  2. If manual typing also fails, try opening the file in a different reader. Adobe Acrobat Reader, Foxit, your browser’s built-in viewer, and macOS Preview each handle password normalization slightly differently. A file that rejects in one may accept in another.
  3. Check for case sensitivity and look-alike characters. O and 0, l and 1, S and 5 are easy to mistype. Smart quotes from chat apps ("like this") replace straight quotes ("like this") silently and never match the original.

If one of those resolves it, you’re done. The rest of this page covers the more involved cases.

If that didn’t work

Inspect the encryption parameters to understand what kind of encryption is on the file. Open a terminal and run:

qpdf --show-encryption your-file.pdf

This works without supplying a password and tells you the encryption version. The version matters because it changes how the password is processed.

If you see R = 2, R = 3, or R = 4, the file uses legacy encryption (RC4-based, PDF version V < 5). These files encode passwords using PDF DocEncoding, which is essentially Latin-1 with PDF-specific overrides. Unicode characters in the password — accented letters, em-dashes, anything outside basic ASCII — may have been encoded in unexpected ways depending on the tool that created the file. Try the password as plain ASCII first; if it contains accented characters, try the same password with those characters replaced by their unaccented equivalents.

If you see R = 5 or R = 6, the file uses AES encryption (PDF version V = 5 or V = 6). These versions use SASLprep for Unicode normalization, which is much stricter and more predictable. Encoding mismatches are rare here. The problem is more likely to be in your input.

Once you’ve confirmed the encryption type, try qpdf to verify the password works at all:

qpdf --password=YOURPASSWORD --decrypt input.pdf output.pdf

If qpdf accepts the password and produces an output file, the password is structurally correct and the original reader was the problem. Use the unencrypted output. If qpdf also rejects the password with invalid password, the input you have is genuinely not the right password, and the rest of this page won’t help — see the guide to lost PDF passwords for what to do next.

Advanced recovery

For legacy-encrypted files where the password contains non-ASCII characters and qpdf still rejects it, the encoding mismatch theory is the prime suspect. Different PDF creators in the V < 5 era encoded user passwords inconsistently — some used Latin-1, some used the PDF document’s declared encoding, some used UTF-8 incorrectly stuffed into a Latin-1 byte stream. There is no clean way to enumerate all possibilities, but the common ones to try are:

  • The password as you understand it, in plain ASCII (substitute e for é, a for ä, etc.)
  • The password with each non-ASCII character replaced by its closest visual equivalent
  • The password truncated at the first non-ASCII character (some tools silently truncated)

Try each variant with qpdf --password=VARIANT --decrypt. This is brute-force in spirit but limited in scope; you’re not cracking the password, just enumerating the small number of ways the original tool may have encoded it.

If none of those work and you’re sure the password is correct, the encryption dictionary may be corrupted. This is rare but possible — it happens when a file is partially edited by a tool that didn’t fully rewrite the encryption parameters. Running qpdf --check input.pdf will report structural problems it can detect without the password, though full encryption-dictionary verification requires the password. There is no clean recovery for a damaged encryption dictionary: the encryption metadata is the authoritative description of how the password is checked, and if it’s wrong, no password will validate. The file effectively needs the original creator to reproduce it without encryption.

Why this happens

PDF encryption is a layered system, and most password-rejection problems happen in the layer between your fingers and the file rather than in the file itself.

When you paste a password from a chat message, an email, or another document, the source application often adds invisible formatting — a trailing space from where you double-clicked, smart-quote substitution from autocorrect, a non-breaking space instead of a regular space. The PDF reader sees these as part of the password and the comparison fails. The file is intact; your input is the problem.

Encoding is the second common cause, and it only affects PDFs created with older RC4-based encryption (PDF versions before V = 5, roughly meaning files created before 2017 or by older software). The PDF specification before version 2.0 was vague about how non-ASCII passwords should be encoded, and different tools encoded them differently. The same password — say, one containing the character é — could have been stored as Latin-1 byte 0xE9, or as UTF-8 bytes 0xC3 0xA9, or as the closest ASCII equivalent e. When a different reader tries to validate, it picks one encoding and either matches or doesn’t. Modern AES encryption (V = 5 and later) uses Unicode normalization, which removes this ambiguity.

Encryption dictionary corruption is the third cause and the only one that genuinely lives in the file. It happens when a tool rewrites part of a PDF without correctly updating the /Encrypt dictionary, leaving the encryption parameters in an inconsistent state. The file looks intact but no password will validate. This is rare and hard to fix.

Preventing this in future

A few practices avoid most password-rejection trouble going forward.

Store PDF passwords in a password manager rather than emailing or chatting them. Password managers preserve exact characters without smart-quote substitution or trailing whitespace.

When creating a password-protected PDF, use AES-256 (V = 5 or V = 6) rather than the legacy RC4 algorithms. Modern Acrobat, qpdf with --encrypt user owner 256, and most modern PDF editors default to AES. Legacy encryption is both weaker security and more prone to encoding ambiguity.

If you must share a password-protected PDF in a context where copy-paste is likely, restrict the password to ASCII characters. It avoids the encoding ambiguity entirely.

If the password is genuinely lost rather than rejected, the guide to lost PDF passwords covers what is and isn’t recoverable. If qpdf reports the encryption dictionary itself is damaged, the PDF repair pillar covers structural recovery, and the guide to “file is damaged and cannot be repaired” covers the related case where Adobe’s catch-all error fires for any damage class. For users who want to know more about qpdf’s password and encryption options, the complete guide to qpdf covers the full set of encryption-related commands.

Last verified: April 2026