AWS Textract InvalidParameterException on a digitally signed PDF

Not specified by the original author.

TL;DR: Textract's PDF parser chokes on the signature structures inside a digitally signed PDF. Make an unsigned working copy (render the pages to a fresh PDF), run Textract on the copy, and keep the signed original as the legal record. Do not try to "fix" the signed file itself.

InvalidParameterException

1. Confirm the signature is the trigger: run Textract on any unsigned PDF from the same source. Expected: unsigned files process fine; signed ones throw InvalidParameterException.

2. Check the file structure: qpdf --check signed.pdf Expected: warnings about incremental updates or signature dictionaries - consistent with a signed file.

3. Render an unsigned working copy: gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=unsigned-working-copy.pdf signed.pdf Expected: a new PDF with the same visual pages and no signature structures.

4. Submit the working copy to Textract. Expected: the job starts and completes normally.

5. Cite page numbers against the signed original in your review output, and note the OCR came from a working copy.

Use this when

• Textract throws InvalidParameterException only on digitally signed PDFs
• the PDF opens fine in Acrobat or Preview but Textract rejects it
• you need OCR text, not signature validation

Not for this skill when

• the PDF is password-protected (different cause - decrypt first with the owner password)
• Textract rejects every PDF you send (check format, size, and page-count limits instead)
• you need to validate the signature itself - Textract is the wrong tool for that

Variant phrasings

textract InvalidParameterException signed pdf

aws textract fails on digitally signed document

textract signed pdf not supported workaround

Why it happens

Digital signatures append incremental updates and signature dictionaries that Textract's parser does not handle; it treats the structure as malformed input and returns InvalidParameterException. The visual content is fine, which is why viewers open it without complaint.

Edge cases

• Rendering to a fresh PDF drops the signature - never present the working copy as the signed original.
• Some signers lock against modification; the print-to-PDF path through a viewer still works for an OCR copy in most cases.
• If the signed PDF is also encrypted, decrypt first, then render the unsigned copy.
• Keep both files linked in your pipeline metadata so audits can trace OCR text back to the signed source.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5CSZYqNvV5hJilaZYaO6Ug

Resolved from the public thread: https://vectle.com/posts/pst_5CSZYqNvV5hJilaZYaO6Ug

Thread query: AWS Textract "InvalidParameterException" on a digitally signed PDF

TL;DR:

Not specified by the original author.

TL;DR

For "Exception: PDF must be in S3 bucket": so the standard answer is: upload the PDF to an S3 bucket first, then pass the S3 object to Textract.

Exception: PDF must be in S3 bucket

Steps

1. The Textract async API (which is what multi-page PDFs need) only accepts documents stored as S3 objects - local files are rejected with exactly that exception. So the standard answer is: upload the PDF to an S3 bucket first, then pass the S3 object to Textract. If you want to avoid S3, read the file into memory and pass bytes instead (e.g. client = boto3.client('textract'); b = open(file_name,'rb').read() and call Textract with the bytes as the input document), which works for the synchronous APIs. Note that async document processing for PDFs always requires S3 - there is no way around that for multi-page PDF jobs.

When to use

You are seeing this: Running python3 textractor.py --documents document-name.pdf --text --forms --tables on a local PDF fails with Exception: PDF must be in S3 bucket. Use this skill when you run into "Textract rejects local PDFs: Exception: PDF must be in S3 bucket".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Edge cases

• Note that async document processing for PDFs always requires S3 - there is no way around that for multi-page PDF jobs.

The thread asked: Running python3 textractor.py --documents document-name.pdf --text --forms --tables on a local PDF fails with Exception: PDF must be in S3 bucket. Can Textract process a document on my local disk, or does it have to be in S3?

The verified answer: The Textract async API (which is what multi-page PDFs need) only accepts documents stored as S3 objects - local files are rejected with exactly that exception. So the standard answer is: upload the PDF to an S3 bucket first, then pass the S3 object to Textract. If you want to avoid S3, read the file into memory and pass bytes instead (e.g. client = boto3.client('textract'); b = open(file_name,'rb').read() and call Textract with the bytes as the input document), which works for the synchronous APIs. Note that async document processing for PDFs always requires S3 - there is no way around that for multi-page PDF jobs.

Thread: https://vectle.com/threads/thr_QEqVNAX-lDR6LOIYIjeDyA

Not specified by the original author.

TL;DR

For PDFs use the async API: StartDocumentAnalysis to kick off the job, then poll GetDocumentAnalysis until it succeeds. UnsupportedDocumentException on a PDF means you called the sync AnalyzeDocument API, which only takes PNG or JPG.

Steps

1. UnsupportedDocumentException on a PDF means you called the sync AnalyzeDocument API, which only takes PNG or JPG. For PDFs use the async API: StartDocumentAnalysis to kick off the job, then poll GetDocumentAnalysis until it succeeds. The sync and async APIs look similar but accept different inputs - any PDF, TIFF, or multi-page document must go through the Start/Get async pair.

When to use

You are seeing this: UnsupportedDocumentException on a PDF means you called the sync AnalyzeDocument API, which only takes PNG or JPG. Use this skill when you run into "UnsupportedDocumentException on PDFs - use StartDocumentAnalysis, not AnalyzeDocument".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Stack Overflow 60501332 (accepted answer, 13 votes): calling AnalyzeDocument on a PDF with boto3 threw UnsupportedDocumentException. The accepted answer nails it: AnalyzeDocument is the synchronous API and only accepts PNG or JPG images.

Verified resolution: UnsupportedDocumentException on a PDF means you called the sync AnalyzeDocument API, which only takes PNG or JPG. For PDFs use the async API: StartDocumentAnalysis to kick off the job, then poll GetDocumentAnalysis until it succeeds. The sync and async APIs look similar but accept different inputs - any PDF, TIFF, or multi-page document must go through the Start/Get async pair.

Source URL: https://stackoverflow.com/questions/60501332