Validate

Any PDF file you would like to process with pdfcpu needs to pass validation.

Validation checks the PDF structures and objects covered by pdfcpu’s implemented validation rules against:

• PDF 1.7: PDF 32000-1:2008

• PDF 2.0: basic checks against PDF 32000-2:2020 (ongoing task)

Validation is not a certification of complete ISO 32000 compliance. PDF 2.0 coverage is basic and continuously improving.

Have a look at some examples .

Usage

pdfcpu validate inFile... [flags]

Flags

Common Flags

Arguments

Mode

Strict

Strict validation rejects specification violations detected by pdfcpu’s implemented validation rules.

It validates against PDF 32000-1:2008 (PDF 1.7) and performs basic PDF 32000-2:2020 (PDF 2.0) checks.

Relaxed

Relaxed validation is the default and is intended for processing real-world PDFs.

It applies the same validation baseline as strict mode but permits a curated set of common PDF writer deviations. Depending on the violation, pdfcpu may accept an alternate representation, tolerate a missing or inconsistent entry, or apply a safe, unambiguous repair to the in-memory document.

Relaxed mode broadens compatibility; it does not relax security or resource limits. Unreadable input, ambiguous corruption, unsafe structures, and violations outside the supported compatibility exceptions still fail validation.

Compatibility warnings

A compatibility warning explains when relaxed validation accepts a PDF condition that strict validation would reject. It reports whether the condition was accepted as-is, skipped or repaired in memory. --quiet suppresses these warnings.

Not every compatibility rule produces a warning yet. To determine whether a PDF is strictly compliant, run strict validation instead of relying on the absence of warnings.

Go callers can obtain structured warnings using api.ValidateWithReport, api.ValidateFileWithReport or api.ValidateContextWithReport.

Reader recovery

Validation mode controls conformance decisions, not every aspect of PDF parsing. The reader may perform bounded recovery of low-level structures, such as damaged cross-reference information, in either mode when reconstruction is unambiguous.

Consequently, strict validation does not mean that the original byte stream was free of defects. It means that the document pdfcpu reconstructed passed the strict checks currently implemented.

JavaScript and media presence

Starting with v0.16.1, validation reports JavaScript and supported sound, movie and Rendition content in both modes. These notices identify content presence; they do not display script code. --quiet suppresses the notices, and Go callers can obtain them through the report-returning validation APIs listed above.

Validation checks the implemented structural rules without executing JavaScript or playing media. A PDF containing this content can still produce validation ok; that result does not certify the behavior or safety of its contents.

External links

Use --links to assess external targets collected during validation.
Starting with v0.16.1, HTTP and HTTPS checks block private and local network addresses, including redirect destinations. Link checking has a fixed budget of 100 HTTP attempts per document, including redirects.
File targets are not opened and executable targets are not run.

URL passwords are redacted from CLI output and validation notices.
With --offline, targets are assessed without HTTP requests, and HTTP checks are reported as skipped.

Strict validation with --links fails if a link is blocked, skipped or fails its check. Relaxed validation records these results as skipped notices and can complete successfully. Successful HTTP checks are listed with --verbose.

Scope

Strict and relaxed are validation policies. They do not select a PDF/A profile, provide complete PDF 2.0 validation, or constitute a signature trust, legal-validity, or regulatory-compliance assessment.

Validation coverage grows between releases. A PDF that passed strict validation in an older release may fail when pdfcpu adds a check for a previously uncovered rule. Use relaxed mode for broad real-world compatibility and strict mode when detected specification violations must be rejected.

Progress

Use --progress together with --quiet for quiet batch validation that still identifies each input as processing starts. Progress and validation errors are written to standard error; normal success output remains suppressed.

Without --quiet, validation already reports the current input and --progress does not print a duplicate line.

For large directory trees, see Corpus Validation for recursive runs, progress logging, result interpretation, and reporting guidelines.

Examples

An example using strict validation:

$ pdfcpu validate test.pdf --mode strict
validating(mode=strict) test.pdf ...
validation ok

An example using default validation:

$ pdfcpu validate test.pdf
validating(mode=relaxed) test.pdf ...
validation ok

Quietly validate a directory while reporting each input as processing starts:

$ pdfcpu validate --quiet --progress invoices
validating(mode=relaxed) invoices/invoice-001.pdf ...
validating(mode=relaxed) invoices/invoice-002.pdf ...

Check for broken links:

$ pdfcpu val PDF32000_2008.pdf -l
validating(mode=relaxed) PDF32000_2008.pdf ...
validating URIs..
...........................
Page 8: http://www.aiim.org/pdfrefdocs status=404
Page 10: http://adobe.com/go/pdf_ref_bibliography status=404
Page 10: http://www.adobe.com/go/pdf_ref_bibliography status=404
Page 11: http://www.aiim.org/pdfnotes status=404
Page 753: http://developer.apple.com/fonts/TTRefMan/ status=404
Page 754: http://www.agfamonotype.com/printer/pan1.asp status=404
Page 755: http://www.rsasecurity.com/rsalabs/node.asp?id=2125 status=404
validation error: broken links detected

Validate a PDF streamed from S3:

$ aws s3 cp s3://acme-invoices/invoice.pdf - \
   | pdfcpu validate -