ocrmypdf 'PDF/A conversion failed' on a signed contract with embedded signatures

TL;DR

ocrmypdf's 'PDF/A conversion failed' on a signed contract is the converter refusing to silently break your signatures: PDF/A conversion rewrites the document, which invalidates embedded digital signatures and drops signature annotations. Use --output-type pdf instead of the default PDF/A output to keep it a regular PDF with the OCR layer and intact signatures. If you genuinely need PDF/A, OCR an unsigned copy first and apply signatures afterward - never convert a signed original.

The query

ocrmypdf 'PDF/A conversion failed' on a signed contract with embedded signatures

Use this when

• ocrmypdf fails with 'PDF/A conversion failed' on a signed contract
• The PDF has visible signatures or embedded signature fields
• Unsigned PDFs convert fine with the same command

Not for

• ocrmypdf failures on unsigned PDFs - those are different errors (OCR engine, permissions, corrupt input)
• Signature validation failures unrelated to OCR - check the certificate chain instead
• PDF/A validation failures after a successful conversion - a compliance tuning problem

Steps

1. Confirm the document carries embedded signatures

Check for signature fields or embedded certs before changing anything. If the contract is signed, the failure is protective, not a bug - the tool is refusing to destroy evidentiary value.

pdfinfo signed-contract.pdf | grep -i -E "sign|encrypt" || echo "check fields manually"

Expected output: evidence of signatures (or inspect the signature panel in a reader to be sure).

2. Switch the output type to plain PDF

Add --output-type pdf so ocrmypdf adds the OCR text layer without attempting the PDF/A rewrite that breaks signatures. Everything else in your command stays the same.

ocrmypdf --output-type pdf signed-contract.pdf signed-ocr.pdf

Expected output: the command completes and signed-ocr.pdf has a searchable text layer.

3. Verify the signatures still validate

Open the OCR'd file in a reader and check the signature panel: signatures should still show as valid. Also verify the OCR layer is actually there by selecting and copying text. Expected output: signatures valid, text selectable - the document gained searchability and lost nothing.

4. For PDF/A needs, reorder the pipeline: OCR first, sign last

If the business requires PDF/A, run ocrmypdf with PDF/A output on the unsigned original, then apply the digital signatures to the converted file. The signed artifact is then both PDF/A and validly signed. Expected output: a PDF/A file whose signatures validate because they were applied after conversion.

Tool compatibility

ocrmypdf 13+ (--output-type option); any PDF reader with a signature panel for verification. The PDF/A-vs-signature conflict is inherent to the standards, not version-specific.

Variant phrasings

• ocrmypdf PDF/A conversion failed signed contract
• ocrmypdf embedded signatures PDF/A error
• ocrmypdf --output-type pdf signed PDF
• ocrmypdf breaks digital signatures PDF/A

Why it happens

PDF/A is an archival standard that forbids or restricts several PDF features, and its conversion rewrites objects throughout the file. A digital signature is a cryptographic hash over the document's bytes as signed - any rewrite invalidates it by design. ocrmypdf fails the conversion rather than producing a file that looks signed but no longer verifies, because a silently broken signature is worse than no OCR.

Edge cases / pitfalls

• Some 'signatures' are just scanned ink images with no cryptographic value - those survive conversion fine, but verify which kind you have first.
• Certified PDFs (with usage restrictions) may block even the OCR rewrite; those need the certifier's permission, not a flag.
• Keep the signed original archived untouched; the OCR'd copy is a working derivative.
• Approval stamps and annotations can also be dropped by PDF/A conversion - check those too, not just signatures.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst-wDBPH-BhWsedA0EPvUUQ