PDF/A explained: archive PDF basics

PDF/A exists so an archived document can be opened later without depending on missing fonts, remote files, scripts, or passwords. A normal PDF can be perfectly usable today while relying on a system font or external reference that will not exist in a records system years later. PDF/A narrows those choices.

The “A” means archival. It does not mean the file is editable, small, secure, or legally valid by itself. It only means the PDF claims conformance to a preservation profile, and that claim should be validated by a PDF/A checker when the document matters.

PDF/A-1 is based on older PDF 1.4 capabilities. PDF/A-1b focuses on visual preservation: the pages should look the same when rendered. It does not require preserving reading order or semantic structure.

PDF/A-2 allows later PDF features such as JPEG 2000 compression, transparency, and layers under controlled rules. PDF/A-3 is similar to PDF/A-2 but permits arbitrary embedded files, such as XML or CSV attachments. The “b” level still means basic visual conformance rather than full accessibility tagging.

Common forbidden features include JavaScript, audio and video, encryption, executable actions, and references to external content. Fonts must be embedded so text can render without the viewer finding a substitute. Color handling must be explicit enough for repeatable rendering.

Encryption is a frequent surprise. A password-protected PDF cannot be PDF/A-conformant because preservation systems must be able to render it without hidden keys. If a records workflow needs access control, apply it in the repository, not by encrypting the PDF/A file.

Use a validator when compliance matters. Basic command-line checks can still catch obvious problems. pdffonts in.pdf shows whether fonts are embedded. If it lists fonts as not embedded, the file will not meet PDF/A requirements.

Text extraction is separate from PDF/A. pdftotext in.pdf - | wc -w can tell you whether a file has extractable text, but a scanned PDF/A can still have zero words if it contains only page images. PDF/A preserves appearance; it does not automatically add OCR.

Converting to PDF/A can change a file. The converter may embed replacement fonts, flatten transparency, remove actions, discard attachments for PDF/A-1, or rewrite metadata. That is normal if the source used features the target profile forbids.

For scanned records, run OCR before or during archival conversion if searchability is required. For born-digital documents, export from the authoring application with PDF/A enabled when possible, then validate. A later repair step can work, but the original application usually knows more about fonts and structure.

PDF/A validation should be part of the workflow, not an assumption based on the export button. A file can contain XMP metadata claiming conformance and still fail validation because of an unembedded font, transparency rule, attachment, or action. Use a validator when the file enters a records system.

Preservation also needs policy outside the file. Store the source, the produced PDF/A, validation logs, and conversion settings when the document is important. PDF/A reduces technical dependencies, but it does not describe who approved the file or whether the source was complete.

A final archive workflow should also define naming, retention, and validation failure handling. A rejected PDF/A file should go back to the source owner with a specific reason, not disappear into a manual repair queue.