File Formats
You've submitted a document to a government portal, a court system, or a university archive, and you've received an error: "Please submit documents in PDF/A format." Or maybe you're setting up a document management system and someone on the team mentions PDF/A compliance. What actually is PDF/A, why does it exist, and — more importantly — do you need to care about it? This guide explains the standard clearly, without the ISO jargon.
In the late 1990s and early 2000s, government agencies, law firms, and archives were digitizing their records en masse, saving millions of documents as PDFs. PDF was an obvious choice — it was widely supported, layout-preserving, and printable. But there was a fundamental problem with using standard PDFs for long-term preservation.
Regular PDFs can depend on things that might not exist in the future. They can reference fonts that are installed on the creating computer but not embedded in the file. They can contain JavaScript that executes when the document is opened. They can link to external resources like images or audio files hosted at a URL that may be gone in ten years. They can be encrypted, preventing future software from reading them even for legitimate archival purposes. And they can contain proprietary data streams that only specific software versions understand.
Consider the problem concretely: a legal contract stored as a PDF in 2005 that referenced a non-embedded proprietary font might look completely different in 2025 when that font is no longer available on any system. For something as critical as a medical record, a property deed, or a court filing, that's unacceptable.
PDF/A was the answer. Published as ISO 19005-1 in 2005, it's a strict subset of the PDF specification designed with one mission: to ensure a document can be rendered exactly as intended by any conforming reader, on any system, decades into the future.
PDF/A achieves its preservation guarantees not by adding features to PDF, but by removing features that could create external dependencies or unpredictable behavior. Here's what's banned:
PDF/A also requires the file to include document-level metadata in a specific format (XMP), declaring that the file conforms to the standard and specifying which version of PDF/A it uses. This metadata declaration is what allows compliance-checking software to verify a file.
PDF/A isn't a single standard — it's a family of standards that have been refined over time as PDF itself has evolved. Understanding which version you need matters when creating or checking compliant files.
The original standard, based on PDF 1.4. The most restrictive version: no transparency, no layers, no attachments. PDF/A-1b is the most common conformance level (visual appearance preserved); PDF/A-1a adds additional requirements for document structure and accessibility (tagged PDF). If you're filing with an older government system or court that specifies "PDF/A," this is often what they mean.
Based on PDF 1.7. Allows transparency, JPEG 2000 image compression, optional content groups (layers), and embedding of other PDF/A files as attachments. Significantly more capable than PDF/A-1 for complex documents. PDF/A-2b, PDF/A-2a, and PDF/A-2u (Unicode) are the three conformance levels.
Extends PDF/A-2 by allowing any file type to be attached to the PDF/A file — not just other PDF/As. This matters for "hybrid" archiving scenarios where you want to attach the source spreadsheet (e.g., .xlsx) alongside the rendered PDF. Increasingly used in electronic invoicing standards in Europe (ZUGFeRD, Factur-X).
PDF/A was designed for organizations that need to retain documents reliably for many years — often with legal or regulatory obligations attached. The canonical users are:
Public records, court filings, permits, licenses, and official correspondence increasingly require PDF/A. Many courts in the US, EU, and Australia mandate PDF/A for electronic filing systems. The reasoning is sound: a court document submitted in 2024 may need to be retrieved and verified in 2050. It cannot rely on specific software or fonts that may not exist then.
Contracts, deeds, wills, and corporate records are routinely kept for decades. Many law firms have adopted PDF/A as their internal archiving standard for all signed agreements. It's also increasingly required for e-discovery submissions in major litigation.
Medical records in many jurisdictions must be retained for 7–30 years depending on the type and the patient's age. Patient records, imaging reports, surgical notes, and consent forms stored as PDF/A are readable regardless of what EHR software the practice uses in the future.
Theses, dissertations, and institutional research are typically archived permanently. Many university libraries and repositories require PDF/A for doctoral theses in particular — the Networked Digital Library of Theses and Dissertations (NDLTD) recommends it.
Financial statements, audit reports, and tax records that must be retained under securities or tax law are natural candidates for PDF/A archiving. The stability guarantees are particularly valuable when documents may be reviewed by auditors or regulators years after creation.
Creating a true PDF/A-compliant file requires software that supports the standard explicitly. You can't just rename a PDF or hope it's compliant — the software must actively write the required metadata, embed all fonts, and exclude disallowed features during export.
-dPDFA=1 flag with the appropriate PDF/A definition file. Powerful but requires command-line knowledge.There are several ways to verify PDF/A compliance before submitting a document:
| Feature | Regular PDF | PDF/A |
|---|---|---|
| Font embedding required | Optional | ✅ Mandatory |
| Encryption allowed | Yes | ❌ Prohibited |
| JavaScript | Allowed | ❌ Prohibited |
| External links and resources | Allowed | ❌ Prohibited |
| Audio/video content | Allowed | ❌ Prohibited (A-1/A-2) |
| Compliance metadata required | No | ✅ Required (XMP) |
| Long-term rendering guarantee | Not assured | ✅ By design |
| File size | Varies | Typically larger (embedded fonts) |
For the vast majority of people reading this article, the answer is no. If you're converting a photo to PDF to email to someone, creating a PDF from a Word document to send to a client, or archiving your own personal records, regular PDF is perfectly appropriate. The self-contained nature of standard PDF already ensures good readability across devices, and the practical rendering problems PDF/A was designed to prevent — missing fonts, expired external links — are increasingly uncommon with modern PDF creation tools that embed fonts by default.
PDF/A matters when you have a specific mandate, when documents must be legally or institutionally archivable for extended periods, or when you're submitting to a system that explicitly requires it. It's a specialist standard for specialist needs — important in the contexts it was designed for, and unnecessary overhead for everyday document use.
If you're submitting to a system that requires PDF/A, use Microsoft Word's built-in PDF/A export option or LibreOffice's PDF export — both are free and reliable for PDF/A-1b compliance. Validate with veraPDF if compliance is critical. And if you're just saving a document for your own records, a regular PDF from BuildPDF will serve you perfectly well for years to come.
Free, instant, no sign-up. Your files never leave your device.
Convert to PDF Now →