Why does ClientPDF say my file may be corrupted or password-protected?

ClientPDF uses pdf-lib, a browser-based PDF library, to open every file you drop in. When pdf-lib detects that a PDF is encrypted, it refuses to load it and throws an error rather than guessing at a password. ClientPDF can't tell the difference between that specific error and a genuinely corrupted file, so it shows one message covering both cases.

Can ClientPDF ask me for the PDF's password and unlock it?

No. None of ClientPDF's tools implement a password prompt or decryption step — they call pdf-lib in its default mode, which stops at the first encrypted file rather than opening it. Adding that would mean handling the password in the same tab as the rest of the processing, which is a feature ClientPDF hasn't built.

How do I merge, split, or edit a password-protected PDF?

Remove the password first using whatever tool originally set it — most PDF viewers, including Preview on macOS and Adobe Acrobat, can save an unlocked copy once you enter the correct password. Once you have that unlocked copy, ClientPDF's merge, split, rotate, reorder, compress, and page-numbering tools will work on it normally.

Why can't I open my password-protected PDF here?

ClientPDF Guide · a 2-minute read

You dropped in a PDF and got back "This file may be corrupted or password-protected" — except you know the file opens fine elsewhere, it just needs a password first. The message isn't wrong, it's just covering two different problems with one sentence. If your file has a password on it, that's what's actually happening.

pdf-lib stops at encrypted files on purpose

Every tool on this site — merge, split, rotate, reorder, compress, page numbers — loads your file using pdf-lib, a JavaScript PDF library that runs entirely inside your browser tab. When pdf-lib opens a file and finds it's encrypted, it throws an error rather than proceeding: Input document to `PDFDocument.load` is encrypted. That's deliberate on pdf-lib's part — it won't silently guess at a password or partially load a file it can't fully decode.

None of ClientPDF's tools catch that specific error and treat it differently from any other file that fails to load, so a password- protected PDF and a genuinely corrupted PDF both land on the same generic message. From the outside they look identical: a file that won't open.

Why ClientPDF doesn't just ask for the password

pdf-lib does have a bypass — loading with { ignoreEncryption: true } — but that only skips the encryption check for PDFs that have restrictions applied without requiring a password to view (things like disabling printing or copying). It does nothing for a file that actually needs a password to be read at all, which is the more common case. Handling that properly means prompting for a password and decrypting the file in the same tab as the rest of the processing, and none of ClientPDF's tools currently do that.

What to do instead

Open the PDF in whatever viewer you normally use — Preview on macOS, Adobe Acrobat, or your browser's built-in PDF viewer — and enter the password there.
Save or export an unlocked copy. In Preview, that's File → Export and unchecking "Encrypt"; in Acrobat, it's under the security or permissions settings for the document.
Bring that unlocked copy back to ClientPDF. Since it's no longer encrypted, pdf-lib will load it the same as any other PDF, and merge, split, rotate, reorder, compress, and page-numbering will all work on it normally.
If you don't have the password and don't own the document, that's not something any client-side tool — this one included — is going to work around, and for good reason.

Try it yourself: once a PDF's password protection is removed, ClientPDF's tools handle it exactly like any other file — instantly, entirely on this device, with nothing ever uploaded.