Announcement

Introducing gopdfrab: PDF/A verification and conversion for Go

Why a new PDF/A implementation, what it does today, what it deliberately does not do, and how it is tested.

gopdfrab verifies PDF documents against PDF/A-1b and converts non-conforming ones. It ships as a Go library, a single static CLI binary and a WebAssembly build, with no CGo and nothing to install alongside it.

Why another PDF/A implementation

You could already validate PDF/A, but you could not do so from inside a Go program. The existing implementations are things you run rather than things you import, and that shapes everything downstream: a subprocess to manage, another tool's output to parse, a deployment that carries a runtime you would otherwise not need.

gopdfrab is pure Go with no CGo, so it cross-compiles anywhere Go does, WebAssembly included, with the API handing back typed errors.

What it does today

Full PDF/A-1b coverage
A PDF/A-1b profile of 159 checks across 11 groups, green on the complete Isartor and veraPDF conformance suites and cross-checked against the veraPDF binary itself in CI.
PDF to PDF/A-1b conversion
Pre-emptive fixups, then a verify/fix loop, with a raster last resort. Anything that survives is reported as a residual, never passed off as valid.
Library and CLI
The same engine as a Go package or a single static script-friendly binary.
Object-model verification
Generic ISO 32000 checks derived from the Arlington PDF Model answer "is this even valid PDF", independent of PDF/A.
Encrypted PDFs
Standard security handler decryption — RC4 40/128, AES-128 and AES-256 — with the empty password or one you supply.
Damage recovery
Report issues in broken documents gracefully and rebuild them where possible.

What it deliberately does not do

PDF/A-2, -3 and -4 are not implemented. They are on the roadmap, and until they land veraPDF is the tool for anything beyond PDF/A-1b. PDF/UA is a different standard again, and is not covered either.

gopdfrab also does not create PDFs. It reads, verifies and rewrites documents that already exist. Generate with a generation library, then verify the output. Check out other Go PDF libraries for that.

How it is tested

The Isartor suite and the veraPDF corpus both pass in full, in CI, next to a differential test against the veraPDF binary itself so a disagreement fails the build. On top of that sits generated broken input and three levels of fuzzing, written up in a separate post.

Status

1.0, and the API is stable
PDF/A-1b verification and conversion are implemented and tested against the full conformance suites. The API is stable as of 1.0, and the changelog states the versioning policy.

Dual-licensed under the AGPL 3.0 or a commercial license. Start at the documentation, or try it on a document of your own in the browser validator.