PDF/A and PDF/X Explained: Archive-Grade PDFs, Print-Ready PDFs, and Who Actually Requires Them

PDF built its reputation on a promise: a document looks the same on every computer. In practice that promise breaks all the time. A PDF that names a font without embedding it gets drawn in whatever the viewer substitutes. A form that stamps today’s date with JavaScript shows a different date every time it opens. A PDF that pulls an image from a web address shows a blank box once that server is gone.

PDF/A and PDF/X exist to close those gaps. Neither is a new file format. Each is a subset of PDF: a list of features that are forbidden and features that become mandatory. What separates them is purpose. PDF/A is about opening the same way decades from now. PDF/X is about coming off a printing press in the intended colors and at the intended size.

What PDF/A forbids and requires

Nearly every PDF/A rule follows from two principles: depend on nothing outside the file, and leave nothing open to interpretation.

Every font must be embedded. The font program for every glyph drawn on the page has to live inside the file, because nobody knows what fonts an operating system will ship in thirty years. The so-called standard 14 fonts, Helvetica and Times among them, are not exempt.

Encryption is forbidden. That includes not just open passwords but permission-only encryption that merely blocks printing or copying. There is no guarantee an archive will still know the password decades later, or that software able to handle that encryption scheme will still exist. The standard’s position is that access control belongs to the repository, not the file.

Color must be device-independent. RGB 255, 0, 0 is a different red on every monitor. PDF/A requires either an OutputIntent carrying an ICC color profile or ICC-based color spaces, so that a viewer far in the future knows what those numbers were supposed to look like.

Nothing may execute. JavaScript, launching external programs, and embedded audio or video are all out. The document has to be what’s drawn, nothing more.

Metadata goes in XMP. Title, author, and the file’s claim of conformance (the pdfaid part and level) are stored as XML metadata.

That last point creates a common misunderstanding. When a PDF viewer shows a banner saying the document complies with the PDF/A standard, or lists PDF/A in the file properties, it has read the XMP claim and nothing more. Anyone can write that claim, and files that carry it while missing embedded fonts are not rare. Conformance can only be established by inspecting the content.

Parts 1 through 4

PDF/A is ISO 19005, split into parts according to the underlying PDF version.

Part	Published	Based on	Notable
PDF/A-1	2005	PDF 1.4	No transparency, layers or JPEG 2000. Strictest and oldest
PDF/A-2	2011	PDF 1.7 (ISO 32000-1)	Allows transparency, layers, JPEG 2000; may attach PDF/A files
PDF/A-3	2012	PDF 1.7	As part 2, but any file type may be attached (XML, spreadsheets…)
PDF/A-4	2020	PDF 2.0 (ISO 32000-2)	Replaces a/b/u levels with a base profile plus 4f (attachments) and 4e (engineering)

Parts 1–3 carry a conformance letter. b (basic) guarantees visual reproduction only. u (from part 2) adds a Unicode mapping for every character so search and copy work reliably. a (accessible) adds a logical tag structure so screen readers know reading order, headings and tables.

PDF/A-3 exists because of a specific demand: send one file that people can read and machines can parse. The German and French ZUGFeRD/Factur-X e-invoices do exactly that, embedding invoice XML inside a PDF/A-3. Archivists tend to treat part 3 with some caution, since nothing guarantees that the attached spreadsheet or XML will itself remain readable.

The level matters most for scans. An image-only scanned PDF can perfectly well be PDF/A-1b or 2b; it has no fonts and no transparency to worry about. But it isn’t searchable, so anywhere that asks for searchable PDF/A needs an OCR text layer too.

Who actually requires PDF/A

The claim that government requires PDF/A is too broad to be useful. The requirements that can be verified tend to attach to a specific moment: submitting to a particular system, or transferring records to a particular institution.

U.S. federal records. The National Archives and Records Administration publishes tables of the formats it accepts when agencies transfer permanent electronic records (NARA Bulletin 2014-04). For textual, page-oriented records, PDF/A-1 and PDF/A-2 are listed as preferred formats, and ordinary PDF versions 1.0 through 1.7 as acceptable. So plain PDF is taken, but PDF/A is what NARA would rather receive. As for federal courts, this article could not confirm a nationwide PDF/A mandate for CM/ECF e-filing. Courts set local rules, so check the specific court’s filing requirements.

Korean public records. Article 36(1) of the Enforcement Decree of Korea’s Public Records Management Act requires public institutions to convert electronic records with a retention period of ten years or more into a document preservation format and a long-term preservation format. In 2008 the National Archives of Korea adopted PDF/A-1 as that document preservation format and issued it as a public standard (as cited in a peer-reviewed Korean archival-science study). This is an internal preservation rule for agencies, not a requirement that citizens submit PDF/A.

Spanish court e-filing (LexNET). Royal Decree 1065/2015, which governs LexNET for courts under the Ministry of Justice, states in Annex IV that the main document of a submission must be presented in PDF/A format with the OCR characteristic. No part or level is named, but searchable text is, so a scanned image wrapped as PDF/A-1b doesn’t meet the letter of the rule.

What these have in common is that they expect a file that passes validation, not a file that merely claims PDF/A. Archive ingest systems validate on transfer, and files that fail are rejected or re-converted.

PDF/X: what printers want

PDF/X (ISO 15930) is concerned with print accidents rather than preservation. What a print shop fears most is a font that silently changes, colors that bear no resemblance to what the designer saw on screen, and a white sliver at the edge after trimming.

So PDF/X, like PDF/A, requires embedded fonts and bans encryption, but its color rules are more specific. The output intent must identify the printing condition the file was prepared for, such as a GRACoL or SWOP condition in North America, FOGRA conditions in Europe, or Japan Color, with the matching ICC profile. Each page also needs a TrimBox (the finished size) and a BleedBox (extra artwork beyond the trim that absorbs cutting error).

The two editions you’ll meet most often behave differently:

PDF/X-1a:2001 requires every color already separated into CMYK and spot colors, and forbids transparency and layers. The printer receives a file with nothing left to decide. It is the most compatible with older output workflows.
PDF/X-4 keeps live transparency, layers and ICC-based color (RGB or Lab), and leaves them for the output device’s RIP to resolve for the actual press. That avoids the hairlines and fattened text that pre-flattening transparency can introduce, and it’s what many current workflows recommend.

If a printer’s instructions say “send PDF/X-1a,” read that as a sign their workflow doesn’t handle live transparency. Sending X-1a to a shop that accepts X-4 is usually fine, with a small risk of flattening artifacts.

For black-and-white work, cleaning up the color itself also helps. A document designed in color and sent to a monochrome process can end up with black text printed as a four-ink rich black that bleeds and wastes toner. The grayscale PDF tool can convert whole pages to gray or clean up black text into a single K ink.

PDF/A and accessibility

Because PDF/A-1a and 2a require tags, it’s tempting to treat them as “accessible PDF.” But level a is mostly about a structure being present. Checking that figures have alternate text, tables have header cells and heading levels don’t skip is the job of PDF/UA (ISO 14289), the dedicated accessibility standard. The two don’t conflict; a single file can claim both PDF/A-2a and PDF/UA-1.

If archival documents will also be published on a public website, it’s worth running a PDF accessibility check for tags, language and alt text, separately from format validation.

Converting is easy; validating is the hard part

Plenty of tools “convert” to PDF/A. Most remove forbidden features and add an output intent and an XMP claim, which isn’t difficult. The hard part is being honest about what can’t be fixed automatically. A font that was never embedded can’t be embedded later without the original font file. At that point a converter has two choices: report the failure, or replace the whole page with an image of itself. The second passes validation but throws away searchable text, which, in LexNET’s case, means breaking one requirement to satisfy another.

That’s why validation should be done by a checker that’s independent of the converter. The reference open-source tool is veraPDF, developed by a consortium led by the Open Preservation Foundation and the PDF Association with EU funding through the PREFORMA project. It reports pass or fail against each ISO clause for every PDF/A part and level, and runs from the command line (verapdf --flavour 2b file.pdf), which is how archives validate transfers in bulk. PDF/X has fewer free validators, so print shops generally rely on commercial preflight such as Acrobat Preflight or callas pdfToolbox.

This site’s PDF/A converter re-reads its own output with a separate checker that shares no code with the converter and reports results clause by clause, but some things, such as glyph-width consistency and XMP extension schemas, aren’t checked. If a submission depends on it, the last step is veraPDF.

A practical order of operations

Embed fonts at export. In your authoring application’s PDF settings, enable font embedding and the PDF/A option if there is one. Most problems a converter can’t fix later disappear here.
Sign last. PDF/A conversion rewrites the file, which invalidates any digital signature added before it.
Check which part and level the recipient wants. If nothing is specified, 2b (or 2u if text must be searchable) is a sound default.
Validate with an independent tool. A viewer’s PDF/A banner is not evidence.
For print, make PDF/X with your printer’s profile. An archival PDF/A built around sRGB, sent straight to press, may arrive with colors never converted for the actual printing condition.