gopdfrab vs veraPDF
Use veraPDF if you need PDF/A-2, -3, -4 or PDF/UA, or if a compliance audit names the reference implementation. Use gopdfrab if you validate PDF/A-1b at volume, want validation inside a Go service rather than beside it, or need to deploy a single binary with no runtime next to it.
Side by side
| gopdfrab | veraPDF | |
|---|---|---|
| PDF/A-1b validation | Yes, passing the whole veraPDF corpus | Yes, reference implementation |
| PDF/A-2, -3, -4 | Planned, not implemented | Yes |
| PDF/UA | No | Yes |
| PDF to PDF/A conversion | Yes, with re-verification | No, validation and repair metadata only |
| Runtime | None, a static binary | JVM |
| Deployment size | 12.3 MB, nothing else | 15.3 MB jar, plus a JRE |
| Batch throughput | 2,939 files/sec | 130 files/sec |
| Cold single file | 9.5 ms | 991 ms |
| Peak memory | 80 MB | 728 MB |
| Embeddable in Go | Native library | Subprocess or REST |
| Runs in the browser | Yes, via WebAssembly | No |
| License | AGPL 3.0 or commercial | GPLv3 / MPLv2 |
Where veraPDF is the better choice
veraPDF is the PDF Association's reference implementation, supported by the PDF industry, holding considerable institutional weight.
It also covers considerably more ground. PDF/A-2 and PDF/A-3 are widely used, and PDF/A-3 in particular underpins ZUGFeRD and Factur-X electronic invoicing. gopdfrab cannot validate either today.
Where gopdfrab fits better
The performance gap in the table is structural rather than incidental. veraPDF pays its startup cost on every invocation, which does not matter in a nightly batch and matters a great deal on a request path.
Deployment differs by less than the raw sizes suggest, and by more than they capture. The two artifacts are comparable in size, but the binary goes into a Lambda bundle or a CI image with nothing alongside it, while the jar needs a JRE to ship and to keep patched.
veraPDF also does not convert PDF to PDF/A, which gopdfrab can.