Azure AI Document Intelligence rejects a password-protected PDF with "InvalidRequest"
Fixes Azure AI Document Intelligence rejecting password-protected PDFs with InvalidRequest. Use when the service refuses an encrypted contract. Key trigger: the API accepts no password parameter, so decrypt to an unlocked working copy first.
TL;DR: The service cannot open encrypted PDFs and the API accepts no password parameter, so stop trying to send the locked file. Decrypt it with the owner password into an unlocked working copy, then analyze the copy. Get the password from the document owner - there is no supported workaround without it.
InvalidRequestRead the full error body, not just the code. Expected: the message mentions the document being password protected or encrypted - that confirms the cause.
Get the owner password from whoever produced the contract (your client, the counterparty, your own vault). Expected: you have the password; without it there is no path forward.
Create an unlocked working copy: run qpdf in decrypt mode with the owner password, writing to a new file. Expected: the new file opens without a password prompt.
Submit the unlocked copy to Document Intelligence. Expected: 202 Accepted and a normal analysis result.
- Delete or vault the unlocked copy per your retention policy; keep the encrypted original as the record.
Use this when
- Document Intelligence returns InvalidRequest on a PDF you know is password-protected
- the same code works on every unprotected file
- a password prompt appears when you open the file locally
Not for this skill when
- the PDF is signed but not encrypted (different failure - see the signed-PDF skill)
- the error body does not mention protection (check file corruption instead)
- you do not have the password and the owner will not share it - the service cannot help you
Variant phrasings
azure document intelligence password protected pdf InvalidRequest
form recognizer encrypted pdf not supported
document intelligence pdf password workaround
Why it happens
Document Intelligence's document parser has no decryption step and the API surface exposes no password field, so any encrypted PDF fails validation before analysis starts. Viewers prompt for passwords interactively; a headless API cannot.
Edge cases
- User password vs owner password - either unlocks for reading, but some files restrict even the owner - verify the copy opens fully.
- Do not brute-force passwords; that is the document owner's call, not a troubleshooting step.
- DRM-protected or rights-managed PDFs may decrypt yet still fail on restricted content streams.
- Automating decryption is only okay with the owner's consent and a logged chain of custody.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_NSinkNMLDNkG0mwWfx6yzQ