The Difference Between PDF and PDF/A
What Is PDF/A?
PDF/A is a family of ISO 19005 standards for preserving a document's static visual representation over time. It is not a different file extension: standard PDF and PDF/A files both normally end in .pdf.
PDF versus PDF/A in one sentence: standard PDF supports a broad set of document features, while PDF/A restricts or requires particular features so a file is less dependent on the software and resources available when it was created.
PDF/A can be useful for records that must remain renderable after the original software is no longer available. It does not, by itself, guarantee permanent access, legal admissibility, accessibility, authenticity, or compliance with every records-retention rule. Those outcomes also depend on choosing the required PDF/A part and profile, validating the file, preserving it in managed storage, and following the rules that apply to the organization and record type.
Standard PDF and PDF/A at a Glance
| Question | Standard PDF | PDF/A |
|---|---|---|
| Primary use | General viewing, exchange, editing, forms, and interactive workflows | Long-term preservation of a stable page-based representation |
| Feature rules | Broad feature set under the applicable PDF specification | Constrained by the selected ISO 19005 part and profile |
| Encryption | May use password-based or certificate-based encryption | Encryption is not permitted in a conforming PDF/A file |
| Proof of conformance | Not applicable | Requires technical validation against the claimed part and profile |
What “Self-Contained” Means in Practice
A standard PDF may already embed fonts, color information, metadata, and other resources. PDF/A makes specific forms of self-containment and predictable rendering part of its conformance requirements. The exact requirements differ among PDF/A versions, but common areas include:
- Fonts: Fonts used to render text must be embedded under the applicable rules. A compliant embedded subset may contain only the glyphs the document uses; PDF/A does not always require an entire font family.
- Color: Output intents and other color requirements reduce reliance on an unspecified display or printing environment. They do not promise that every physical screen or printer will look identical.
- Metadata and identification: A PDF/A file carries structured identification information in XMP metadata and must satisfy additional metadata rules for its claimed version.
- Referenced resources: Resources needed to render the static page appearance cannot depend on unavailable external material.
Features That Are Restricted or Prohibited
PDF/A limits features that could prevent reliable future rendering, but the rules are more nuanced than a list of everything a PDF/A file cannot contain. For example, encryption is prohibited, while embedded-file and engineering features vary by PDF/A version and profile.
- Encryption: A conforming PDF/A document cannot be encrypted. Access control should instead be handled by the archive or records system.
- Active and multimedia content: Common PDF/A profiles restrict JavaScript, audio, video, and similar behavior that depends on execution or external players. PDF/A-4e is a specialized exception designed for certain engineering and 3D content.
- Embedded files: PDF/A-1 does not support attachments. PDF/A-2 permits constrained embedded-file use, PDF/A-3 permits arbitrary file types, and PDF/A-4 includes profiles for newer embedded-file workflows. An embedded attachment is not automatically preservation-friendly merely because its container is PDF/A.
- External hyperlinks: A hyperlink to a website is not categorically forbidden. However, the destination can change or disappear, so an archive should not rely on the link to supply essential page content.
PDF/A-1, PDF/A-2, PDF/A-3, and PDF/A-4
The number after PDF/A identifies a part of the ISO 19005 family, not a quality score. A receiving archive, court, agency, or records policy may require a particular part and conformance level.
| Version | Practical distinction |
|---|---|
| PDF/A-1 | Based on PDF 1.4. It is the oldest and most restrictive part; features such as transparency, layers, and embedded files are not available. |
| PDF/A-2 | Based on PDF 1.7. It supports newer PDF features, including transparency, layers, and JPEG 2000, while constraining attachments. |
| PDF/A-3 | Builds on PDF/A-2 and permits files of any type to be embedded. The visible PDF can conform even when an attachment needs separate preservation controls. |
| PDF/A-4 | Based on PDF 2.0. It modernizes the archival model and adds specialized PDF/A-4e and PDF/A-4f profiles for engineering and embedded-file use cases. |
PDF/A-1 uses the familiar a and b conformance levels. PDF/A-2 and PDF/A-3 add level u. These letters describe different technical requirements; they should not be treated as simple grades. PDF/A-4 changed the profile model and does not use the same a/b/u labels for its base conformance.
PDF/A Does Not “Lock” a Document
PDF/A is a file-format conformance standard, not a tamper-proof seal. A PDF/A file can be modified. After an edit, the resulting file conforms only if it still satisfies every requirement of the claimed PDF/A part and profile. Authenticity and integrity normally require separate controls such as digital signatures, trusted timestamps, checksums, audit logs, and managed storage.
Certificate signatures require special care. Converting or editing a document after it is digitally signed can invalidate the signature. The correct order of conversion, validation, and signing depends on the receiving organization's workflow and should be decided before creating the preservation copy.
Conversion Is Not the Same as Validation
A file can contain metadata claiming that it is PDF/A and still violate the standard. A PDF reader's display mode or notification is useful context, but it is not sufficient proof. Validate the finished file with a conformance checker configured for the intended PDF/A part and profile, then review the report and the rendered pages.
The veraPDF validation documentation explains profile-based checking. The Library of Congress PDF/A format description and the PDF Association's ISO 19005 resource provide additional background on the standards family.
Reproducible PDF vs. PDF/A-2b Test
We created one simple, one-page standard PDF and converted a copy to PDF/A-2b. Both files contain the same visible wording and layout. We then rendered both pages for visual review and tested both files with veraPDF 1.30.2 using its PDF/A-2b validation profile.
| Test file | veraPDF result | Downloads |
|---|---|---|
| Standard PDF 44,413 bytes | Failed PDF/A-2b validation: 3 failed rules and 38 failed checks | Sample PDF Validation report |
| PDF/A-2b copy 21,636 bytes | Passed PDF/A-2b validation: 144 passed rules, 4,632 passed checks, and no failures | Sample PDF/A-2b Validation report |
The standard file failed because it lacked the required metadata stream and RGB output intent and had nonconforming line endings around several stream markers. The PDF/A-2b copy passed the selected profile. In this example, conversion also reduced the file size; that result is specific to these files and is not a general rule about PDF/A.
Testing method: The standard file was generated with ReportLab 4.4.9. The PDF/A-2b copy was prepared offline with OCRmyPDF 15.2.0 and Ghostscript 10.02.1, using OCRmyPDF's pdfa-2 output mode without OCR or optimization. We validated both files with veraPDF 1.30.2, rendered both pages with Poppler, and visually compared the results on August 2, 2026.
This is a reproducible example, not certification of other files. PDF Toolbox does not currently offer PDF/A conversion or conformance certification.
A Safer Archival Workflow
- Identify the record category, retention period, and required PDF/A part or profile before conversion.
- Keep the authoritative source file when policy requires it; PDF/A may be a preservation derivative rather than a replacement for the original.
- Convert with a tool that explicitly supports the required PDF/A target and review any reported conversion problems.
- Validate the completed file and visually inspect text, images, color, page order, links, forms, accessibility, and signatures.
- Store the validated file with checksums, backups, access controls, and documented preservation procedures.
- Revalidate after migration or later processing when the archive's policy calls for it.
Frequently Asked Questions
Is PDF/A always larger than a standard PDF?
No. Embedding fonts and color information can increase size, while font subsetting, image recompression, or structural changes can reduce it. The result depends on the source file, target profile, and converter. File size is not evidence of conformance.
How can I tell whether a file really conforms to PDF/A?
Use a PDF/A validator and select or confirm the required part and profile. A filename, viewer banner, or XMP conformance claim alone is not enough. Review both the validator report and the document's visible content.
Does PDF/A use a different file extension?
No. Standard PDF and PDF/A both normally use the .pdf extension. The distinction is in the file's internal structure, declared conformance, and successful validation against ISO 19005 requirements.
Does PDF/A automatically satisfy legal or regulatory retention rules?
No. A rule may specify a particular PDF/A version, signature method, metadata set, retention schedule, storage control, or audit process. Check the applicable policy or obtain qualified compliance guidance before treating a file as the official archival record.
Is PDF/A automatically accessible?
No. Some PDF/A conformance levels include structural requirements, but archival conformance is not the same as accessibility conformance. A document may also need to meet PDF/UA or other accessibility requirements and should be tested with appropriate tools and users.
Conclusion
Use standard PDF when its broader feature set fits an active document workflow. Consider PDF/A when a defined preservation policy calls for a constrained, self-contained representation intended for long-term retention. The reliable choice is not simply “save as PDF/A”: identify the required profile, convert carefully, validate the result, and preserve it within a managed records process.