Garry Klooesterman
Senior Technical Content Creator
Published March 26, 2026
Updated March 26, 2026
5 min
PDF/A Creation SDK: How to Generate PDF/A-Compliant Documents
Converting Documents for Archival with Apryse
Garry Klooesterman
Senior Technical Content Creator
Summary: Generating PDF/A-compliant documents is all about removing external dependencies. This blog looks at the three main ways to handle this: converting in-memory using a Core SDK, building from the ground up with a Native SDK, or using Template-based automation. We’ll also look at why PDF/A-3 is becoming the standard for hybrid human and machine documents like ZUGFeRD invoices.
Converting Documents for Archival with Apryse
Introduction
If you’ve ever come across a really old PDF in your files, there’s a good chance that when you try to open it, it’ll be a mess. Maybe the fonts are gone, the layout is broken, or some dynamic element just doesn't work anymore. This is what PDF/A was designed to fix. It’s the archival version of a PDF that ensures a file looks exactly the same years from now as it does today.
For industries such as legal, government, or healthcare, PDF/A is usually a strict requirement. But how do you generate these files in a way that doesn't break your existing workflow?
This blog discusses the three main ways to convert PDF files to PDF/A and some commonly asked questions.
Choosing a Conformance Level
Before converting your files, you’ll need to decide which version of PDF/A you need. It can get confusing, but for most modern dev projects, it comes down to two choices:
- PDF/A-2b: This is the current gold standard for general archiving as it supports transparency and layers but keeps the file strictly self-contained. If you don't have a specific legal mandate telling you otherwise, this is a good place to start.
- PDF/A-3: This is the container version. It allows you to embed other files, like XML or CSV, inside the PDF. This is the backbone of the ZUGFeRD invoicing standard.
Read about the different PDF/A versions.
Three Ways to Code PDF/A
You generally have three ways to tackle this, depending on where your data is coming from.
The In-Memory Conversion (Core SDK)
This is probably the most common route. You build your PDF using your normal logic such as placing text, images, and tables, and then run a conversion manager on the document object before saving. The SDK scrubs the file, finding missing fonts to embed and stripping out things that aren't allowed, like JavaScript or certain types of compression.
The Strict Path (Native Creation)
Some libraries, like iText, allow you to initialize a document as a PdfADocument from the very start. If you try to add an image without a color profile or a font that isn't embeddable, the code will give you an error immediately. It’s a steeper learning curve, but it prevents compliance issues from creeping in late in the process. If you’re curious, here are tutorials in Java and .NET (C#).
The Template Route (DocGen)
If you’re generating thousands of invoices or policies, you probably shouldn't be positioning elements manually in code. Instead, you use a template and generation engine like Fluent that maps your data into a pre-configured PDF/A-2b layout.
Here’s a quick comparison table:
Apryse Core SDK | iText (Native PDF/A) | Fluent / DocGen |
|---|---|---|
Model: Post-Build Conversion. You build a standard PDF and then scrub it to meet ISO specs. | Model: Native Creation. You define the PDF/A level upfront, and the API enforces rules during the build. | Model: Template-Driven. A generation engine merges data into a pre-configured archival layout. |
Validation: Post-Creation. Provides a detailed report of fixes, like font embedding, after the save pass. | Validation: Real-Time. Throws errors during development if you add non-compliant elements (like JS). | Validation: Engine-Level. Compliance is handled by the renderer, not by manual coding. |
Best Use: Fixing existing files or converting 20+ formats (Word, HTML) into PDF/A. | Best Use: Building high-performance, compliant docs from scratch with full byte-level control. | Best Use: Scaling high-volume, structured docs like bank statements or insurance policies. |
The ZUGFeRD / Factur-X Standard
One of the coolest uses of PDF/A-3 right now is in electronic invoicing. Standards like ZUGFeRD use PDF/A-3 to create a hybrid file. A human opens the PDF and sees a standard invoice, but an accounting system can look inside and grab an embedded XML file for automatic processing.
The PDF/A part ensures that in 30 years, a human auditor can still see exactly what was billed, even if the software that read the XML is long gone.
Alternative Methods
WebViewer
WebViewer is a fully client-side SDK for high-fidelity document viewing, annotation, conversion, and editing. It supports 30+ formats, including PDF, Office, CAD, images, videos, and websites. For PDF to PDF/A conversion, all PDF/A versions and conformance levels are supported.
Check out the demo.
Xodo
If you’re looking for an easy-to-use online converter, Xodo is your answer. It’s the easiest way to process all your files securely on your browser or mobile. Xodo is a large suite of PDF tools that let you view, annotate, edit, convert to PDF/A and other formats, plus a whole lot more.
FAQ
Why are my PDF/A files larger than standard PDFs?
Because PDF/A is self-contained. In a normal PDF, you might just link to a font like Arial that you assume is on the user's computer. In PDF/A, you have to embed the actual font data, guaranteeing long-term readability.
Can I password-protect a PDF/A?
No. Password protection is an external dependency. If the password or the encryption algorithm becomes obsolete, the document is lost. PDF/A prohibits encryption to ensure the file can always be opened.
What happens if I have an invalid element?
If you use a professional SDK, it will usually try to fix it, like re-compressing an image. If it can't, it will give you a detailed error report. This is why validation is such a big part of the workflow.
Can I include bookmarks and links?
Yes. Bookmarks are totally fine. External links are allowed as well, but they won't be archival. If the website goes down, the link breaks. The document itself will still be readable, though.
Which version should I use?
If you don't have a specific legal mandate, go with PDF/A-2b. It supports transparency and modern compression, making it the most flexible modern archival format.
Conclusion
At the end of the day, PDF/A is about peace of mind. By embedding all fonts and color data inside the file, you’re making sure your work survives any technological shifts. Just remember to use a veraPDF-aligned validator to double-check your work before it hits the archive.
Regardless of the conversion method you choose, Apryse makes it easy to convert your important PDFs for proper archival, ensuring you can still rely on them when you need them most.
Reach out to our sales team for any questions and support.
