Examples
Worked examples
- Is an instance
A university library converts a thesis exported as an ordinary PDF — which relies on non-embedded system fonts and links to an external hosted video — into PDF/A-1b before accepting it into the institutional repository, embedding the fonts and stripping the video reference so the file validates against ISO 19005-1.
- Is an instance
A funder-mandated public report is submitted as PDF/A-2a: it carries tagged structure and reliable Unicode text mapping so a screen reader can navigate its headings in the correct order, on top of the visual-fidelity guarantee every PDF/A file provides at level b.
Counter-examples
Looks similar, but isn't
- Not an instance
A password-protected, DRM-restricted PDF report is not PDF/A-conformant even if it looks identical to a valid PDF/A file on screen — ISO 19005 explicitly disallows encryption in every part and every conformance level, because a proprietary access-control scheme tied to today's software can make the file permanently unopenable once that scheme's supporting infrastructure disappears.
Editorial commentary
PDF/A is the ISO-standardized, restricted subset of PDF defined by ISO 19005, Document management — Electronic document file format for long-term preservation. A file is PDF/A-conformant only if it is self-contained and fully reproducible without depending on anything outside itself: every font used must be embedded (not just referenced), color must be specified in a device-independent way, and the file must contain no encryption, no JavaScript or other executable content, no audio or video, and no reference to external content the renderer would need to fetch to display the page correctly. The goal stated in the standard itself is preserving a document’s static visual appearance — what it looks like on screen or in print — independent of whatever software, fonts, or operating system happen to be available when someone opens it, possibly decades after it was created.
This is why PDF/A is the default requirement, or at minimum the strongly recommended format, for documents deposited in a data repository or institutional archive: an ordinary PDF exported from word-processing or presentation software routinely relies on system fonts that aren’t embedded, may reference external resources, and can carry active content — all of which can render inconsistently, or fail to open at all, once the specific software environment that created it is gone. PDF/A removes that dependency by design.
The four parts of ISO 19005 and their conformance levels
ISO 19005 is published in four parts, each tied to a specific underlying PDF version and each offering different conformance levels. A “conformance level” is not a separate format — it’s a stricter or looser bar a PDF/A file of a given part can be validated against, indicated by a lowercase letter after the part number (e.g. PDF/A-1b, PDF/A-2a).
| Part | Published | Based on | Conformance levels | What it adds |
|---|---|---|---|---|
| PDF/A-1 (ISO 19005-1) | 2005 | PDF 1.4 | b (Basic), a (Accessible) | The original part — visual-appearance preservation (b) plus, at level a, tagged structure and Unicode text mapping for accessibility and reliable text extraction. |
| PDF/A-2 (ISO 19005-2) | 2011 | PDF 1.7 / ISO 32000-1 | b, u (Unicode), a | Adds JPEG 2000 compression, transparency and layers, OpenType font embedding, and the ability to embed one PDF/A file inside another. Level u sits between b and a: it requires reliable Unicode text mapping but not tagged structure. |
| PDF/A-3 (ISO 19005-3) | 2012 | PDF 1.7 / ISO 32000-1 | b, u, a | Identical restrictions to PDF/A-2, with one addition: it may embed a file of any format (XML, CAD, spreadsheet source data, etc.), not only another PDF/A file. Widely used for e-invoicing (e.g. ZUGFeRD/Factur-X) and for bundling machine-readable source data with a human-readable report. |
| PDF/A-4 (ISO 19005-4) | 2020 | PDF 2.0 / ISO 32000-2 | base (tagging optional), f, e | Retires the a/b/u scheme — a base PDF/A-4 file may or may not be tagged. PDF/A-4f permits embedding non-conformant files (like PDF/A-3). PDF/A-4e adds engineering-document features aligned with ISO/TS 24654 (PDF/E) for CAD and technical drawings. |
In practice, most repositories asking for “PDF/A” mean PDF/A-1b or PDF/A-2b at minimum (visual fidelity guaranteed), with level a or u preferred when the deposited document needs to remain searchable or screen-reader accessible. PDF/A-3’s ability to embed arbitrary files is useful but is treated with more caution in preservation planning than PDF/A-1/2, precisely because an embedded non-PDF/A attachment inherits none of the format’s own preservation guarantees — a point the U.S. National Digital Stewardship Alliance flagged directly when evaluating PDF/A-3 for archival use.
What PDF/A disallows, and why it matters for archiving
- No encryption or password protection. A file secured by a proprietary or version-specific encryption scheme becomes unreadable the moment the software that understands that scheme disappears — the opposite of what a preservation format is for.
- No JavaScript or embedded executables. Active content ties a document’s correct rendering to a specific, changing runtime environment rather than to the static content itself.
- No audio, video, or non-embedded fonts. Anything that depends on a codec, a font foundry’s license server, or another external resource being available later is exactly the kind of dependency PDF/A is designed to eliminate.
- Device-independent color required. Color must be specified so it renders consistently regardless of the display or printer used to view it, rather than assuming a specific monitor profile.
Why data repositories and institutional archives require or recommend it
A repository’s preservation commitment is only as good as the formats it accepts. General-purpose data repositories, institutional archives, and university libraries commonly list PDF/A among their preferred or required formats for narrative documents (reports, theses, consent forms, protocols) precisely because it removes the rendering risk described above at the point of deposit, rather than trying to fix it retroactively during a future format-migration cycle. This is the same logic behind requiring complete core metadata at deposit — both are steps that are cheap to do once, at ingest, and expensive or impossible to reconstruct later.
Repositories pursuing CoreTrustSeal certification are required to define and document the “preferred formats” they commit to keeping usable over the long term as part of their preservation policy. PDF/A is a common choice within that preferred-formats list for narrative and textual deposits specifically because its restrictions (embedded fonts, no encryption, no external dependencies) are exactly what a format needs to satisfy a long-term readability commitment — several published CoreTrustSeal-certified repositories’ applications name PDF/A-1 explicitly for this purpose. PDF/A is not itself a metadata standard or a repository certification — it solves a narrower, specific problem: making sure a document still looks the way its author intended, and can still be opened at all, long after the software that created it is obsolete.
Related terms
See also: data repository, trusted digital repository, core metadata, checksum verification and fixity checking, CoreTrustSeal certification.
Also known as
ISO 19005 · Archival PDF
Machine-readable encodings
Use in your systems
<role vocab="credit"
vocab-identifier="https://casrai.org/dictionary/"
vocab-term="PDF/A (ISO 19005)"
vocab-term-identifier="https://casrai.org/dictionary/term/pdf-a-iso-19005" />{
"@context": "https://schema.org",
"@type": "DefinedTerm",
"@id": "https://casrai.org/dictionary/term/pdf-a-iso-19005",
"name": "PDF/A (ISO 19005)",
"identifier": "https://casrai.org/dictionary/term/pdf-a-iso-19005",
"description": "A file is PDF/A-conformant only when it validates against one of the four parts of ISO 19005: every font it uses is embedded rather than referenced, color is specified in a device-independent way, and the file contains no encryption, no JavaScript or executable content, no audio or video, and no reference to external content the renderer would need to fetch. These restrictions make the file self-contained and reproducible without depending on the specific software environment that created it.",
"inDefinedTermSet": "https://casrai.org/dictionary/domain/data-infrastructure#set",
"url": "https://casrai.org/dictionary/term/pdf-a-iso-19005",
"sameAs": [
"ISO 19005",
"Archival PDF"
],
"license": "https://creativecommons.org/licenses/by/4.0/",
"publisher": {
"@id": "https://casrai.org/#organization"
},
"dateModified": "2026-07-17T05:22:55",
"inLanguage": "en"
}






