Open a document from 2004 and there is a reasonable chance something has gone wrong with it — a font substituted, a layout shifted, an embedded object that no longer renders, or a file that needs software nobody installs any more.

Organisations that have to keep records for seven, ten or thirty years discover this eventually. PDF/A exists to prevent it: a constrained version of PDF designed so a document renders identically in fifty years as it does today, without depending on anything outside the file.

This guide explains what the standard requires, which version to use, how to convert existing documents, and where PDF/A is genuinely necessary rather than merely tidy.

What PDF/A Is

PDF/A is an ISO standard — ISO 19005 — defining a subset of PDF intended for long-term preservation. The "A" stands for archiving.

Its core principle is self-containment. A conforming file must carry everything needed to render it identically regardless of the software, fonts or systems available when it is opened. That leads to a specific set of requirements and prohibitions.

Required:

  • All fonts embedded, including for any text inside placed graphics
  • Device-independent colour, with ICC profiles embedded where colour is used
  • Standardised XMP metadata identifying the conformance level
  • A structure that renders without external resources

Prohibited:

  • Encryption, which could prevent future access
  • External content references — anything the file needs must be inside it
  • Audio, video and executable content
  • JavaScript and dynamic behaviour
  • Transparency, in the earliest version of the standard

The prohibitions make sense once you consider the timeframe. A document that calls a font from the operating system, or a colour profile from a server, or a script from anywhere, is a document with dependencies that will eventually fail.

Which Version of PDF/A

The standard has four parts, published over fifteen years, each based on a later version of PDF.

PartPublishedBased onAdds
PDF/A-1 (ISO 19005-1)2005PDF 1.4The original. No transparency support
PDF/A-2 (ISO 19005-2)2011PDF 1.7Transparency, layers, JPEG 2000, PDF/A attachments
PDF/A-3 (ISO 19005-3)2012PDF 1.7Identical to A-2 but permits arbitrary file attachments
PDF/A-4 (ISO 19005-4)2020PDF 2.0Modernised; adds a level supporting 3D for engineering

Within most parts there are also conformance levels, and this is the distinction that matters more than the part number:

  • Level B (basic) — guarantees the document's visual appearance can be reproduced reliably. It does not require tagging or text structure.
  • Level A (accessible) — everything in level B plus a tagged logical structure, Unicode character mappings and a specified document language. This makes the document reliably extractable and usable with assistive technology.
  • Level U (from part 2 onward) — adds Unicode mappings without requiring the full logical structure. A middle option.

Level A is considerably more demanding to produce, because it requires the same underlying structure as an accessible document. If your organisation has accessibility obligations as well as retention obligations, aiming for level A satisfies both — and the structural work involved is described in how to make a PDF accessible.

Choosing a level in practice

Most organisations should ask their records management or compliance function what is specified, because this is frequently prescribed rather than chosen. Where it is genuinely open:

  • PDF/A-2b is a sensible default for general business records — modern enough to handle real documents, undemanding enough to produce at volume.
  • PDF/A-1b where a recipient or system specifically requires it, which still happens in legal and government workflows.
  • PDF/A-2a or 3a where accessibility matters alongside preservation.
  • PDF/A-3 where you need to attach source data to the archived document — an invoice PDF with the machine-readable data embedded, for instance.

Where PDF/A Is Genuinely Needed

It is not for everything. The cases where it earns its cost share a characteristic: the document must remain readable and faithful long after the systems that created it are gone.

  • Statutory retention. Financial records, tax documentation, employment records and contracts with defined retention periods.
  • Legal and regulatory submissions, where the format is often specified by the receiving body.
  • Court and tribunal filings, many of which prescribe PDF/A explicitly.
  • Public records and archives, where national archive bodies commonly require it.
  • Academic and research deposits, including theses and dataset documentation.
  • Medical and clinical records with long retention obligations.
  • Engineering and construction documentation, which may need to be readable for the life of a structure.

Where it is not needed: marketing material, internal drafts, anything superseded quarterly, and documents whose authoritative version lives in a database anyway. Converting everything to PDF/A is a common over-correction that adds cost without adding protection.

Converting Existing Documents

Most PDF/A work is conversion rather than creation. The process is straightforward in principle and has predictable friction points.

  1. Start from the best available source. Converting a clean original beats converting a document that has been through several edits.
  2. Run OCR first if the document is scanned. A scan converts to PDF/A perfectly happily as an image, and produces an archived document nobody can search. Adding a text layer is what makes the archive useful.
  3. Remove prohibited content. Encryption, JavaScript, embedded media and external links to resources will all block conformance.
  4. Embed all fonts. The most common failure. Where a font cannot be embedded for licensing reasons, it must be substituted — which changes the document's appearance and should be a conscious decision.
  5. Convert colour to a device-independent space with profiles embedded.
  6. Convert and then validate. Producing a file is not the same as producing a conforming file.
  7. Verify the output visually against the original, particularly if fonts were substituted.
Validate, do not assume
A tool reporting "saved as PDF/A" is reporting what it attempted, not what it achieved. Run a validator and keep the report. For a document you are relying on for a ten-year retention obligation, evidence of conformance is part of the record.

Validating and Recording Conformance

What a validator checks

A PDF/A validator tests the file against the specification and reports each violation with a reason — a font not embedded, a colour space without a profile, prohibited content present, metadata missing or inconsistent with the claimed conformance level. That last one is common and easy to miss: a file can claim PDF/A-2b in its metadata while failing the requirements, and only a validator will tell you.

Keeping the evidence

For records held under a retention obligation, the validation report is worth keeping alongside the document. If the archive is ever examined, "we converted these to PDF/A" is a claim; a dated validation report is evidence. For bulk conversions, keep a summary report covering the batch rather than one per file.

Re-checking after any change

Conformance is a property of the file as it stands. Editing a conforming document, adding an annotation, or re-saving it through a tool that does not preserve the standard can silently break it. Where documents may be amended before final archiving, validate at the point the record is closed rather than when it is created.

Practical Limits Worth Knowing

Being clear about these prevents disappointment:

  • PDF/A preserves appearance, not meaning. A level B file guarantees the document looks right. It does not guarantee the text can be searched or extracted reliably — that is what level U and level A add.
  • Conversion can change appearance. Where a font cannot be embedded or transparency must be flattened, the output may differ visually from the original. Check rather than assume.
  • Signatures and encryption conflict with it. PDF/A prohibits encryption, and re-saving a signed document invalidates its signature. Where both matter, the sequence and the relationship between them need deciding deliberately — the mechanics are in electronic versus digital signatures on PDFs.
  • Files are usually larger, because everything is embedded. That is the point, and it is a poor place to economise.
  • It is not a storage strategy. A conforming file on a failing drive is still lost. PDF/A addresses format obsolescence, not media failure or backup.

Building It Into Normal Work

The efficient approach is producing conforming documents at source rather than converting later:

  • Set export presets in Word, InDesign or your document system so archival output is a menu choice rather than a project.
  • Use structured source documents. Real heading styles, alternative text and proper tables make level A achievable rather than painful.
  • Use embeddable fonts in document templates, avoiding licence conflicts at export.
  • Define which document types are archived and to which conformance level, so the decision is made once rather than per document.
  • Validate as part of the process, not as an annual audit exercise.

Most of this is template work, and it overlaps with what makes documents maintainable generally — the same argument made in professional Word formatting services.

Conclusion

PDF/A solves one specific problem: documents that must still render correctly when the software that made them is long gone. It does that by requiring everything to be inside the file and prohibiting anything that could create a dependency.

Choose the conformance level based on what you need to preserve — appearance alone, or appearance plus reliable text and accessibility. Apply it to documents with genuine retention obligations rather than to everything. And validate the output, because a tool's claim of conformance is not evidence of it.

This is a general overview of the PDF/A standard. Retention requirements and prescribed formats vary by jurisdiction, sector and record type, so confirm what applies to your organisation.

Getting Documents Archived Properly

SBTEXMEDIA handles PDF/A conversion and archival document preparation for businesses, legal firms, healthcare providers, schools, publishers, NGOs and government organisations — conversion to the required conformance level with validation reports, OCR for scanned material so archives remain searchable, font embedding and substitution decisions made explicitly, removal of prohibited content, and export presets set up so future documents conform on creation rather than needing conversion.

Related work on PDF accessibility, document security and redaction and scanned document conversion is handled by the same team, which matters when archived records also carry accessibility or disclosure obligations.

You can see examples on the portfolio, browse the full range of services, or tell us what you need to retain and for how long for a fixed quote and a delivery date before work begins. More guides are on the SBTEXMEDIA blog.

Frequently Asked Questions

PDF/A is an ISO standard — ISO 19005 — defining a subset of PDF intended for long-term preservation. Its core principle is self-containment: a conforming file must carry everything needed to render it identically regardless of the software, fonts or systems available when it is opened. Fonts must be embedded, colour must be device-independent, and encryption, external references, audio, video and JavaScript are prohibited.
Four parts. PDF/A-1 (2005) is based on PDF 1.4 and does not support transparency. PDF/A-2 (2011) is based on PDF 1.7 and adds transparency, layers and PDF/A attachments. PDF/A-3 (2012) is identical to A-2 but permits arbitrary file attachments. PDF/A-4 (2020) is based on PDF 2.0. Most also have conformance levels within them.
Level B guarantees the document's visual appearance can be reproduced reliably, but requires no tagging or text structure. Level A adds a tagged logical structure, Unicode character mappings and a specified document language, making the document reliably extractable and usable with assistive technology. Level U, available from part 2 onward, adds Unicode mappings without the full logical structure.
Ask your records management or compliance function first, because it is frequently prescribed. Where it is genuinely open, PDF/A-2b is a sensible default for general business records. Use PDF/A-1b where a recipient or system specifically requires it, a level A variant where accessibility matters alongside preservation, and PDF/A-3 where source data needs attaching to the archived document.
No. A scan converts to PDF/A perfectly happily as an image and produces an archived document nobody can search. Run OCR first to add a text layer — that is what makes the archive useful rather than merely compliant.
No. PDF/A prohibits encryption, because it could prevent future access — which is the opposite of what an archive is for. Where both confidentiality and archiving matter, the access control has to live in the storage system rather than in the file.
Run a validator. A tool reporting that it saved as PDF/A is reporting what it attempted, not what it achieved — a file can claim conformance in its metadata while failing the requirements. For records held under a retention obligation, keep the validation report alongside the document as evidence.
No, and converting everything is a common over-correction. It earns its cost where documents must remain readable and faithful long after the creating systems are gone — statutory retention, legal and regulatory submissions, court filings, public records, research deposits, medical records and long-life engineering documentation. Marketing material and internal drafts do not need it.
BK

Bayazid Kajol

Founder of SBTEXMEDIA

Bayazid Kajol is a document specialist and the founder of SBTEXMEDIA, working with businesses, HR departments, schools, hospitals, consultants, legal firms, NGOs and government organisations on professional PDF editing, fillable PDF forms, interactive PDF form design and Microsoft Office document formatting. Every guide on this blog comes out of real client projects rather than theory. Get in touch if you have a document that needs fixing properly.