"Just send it as a PDF" sounds unambiguous, but it isn't. Behind the .pdf file extension sits a whole family of ISO standards that restrict the same base format for very different purposes: archiving, professional printing, accessibility. Anyone sending a PDF to a print shop, a long-term archive or a public authority often has to meet one specific profile – otherwise the file is rejected. This article explains the three most important sub-standards, PDF/A, PDF/X and PDF/UA, what they're for and how they differ.

Why PDF sub-standards exist at all

The normal PDF (standardized as ISO 32000 since 2008) is deliberately flexible. It may reference system fonts, mix RGB and CMYK colors, use transparency, run JavaScript, be encrypted or embed external resources. For a document you read once on screen, that's perfectly fine.

For specialized use cases, that very freedom is a problem. A printing press needs clearly defined colors and embedded fonts. An archive must guarantee that the file looks identical 30 years from now. A screen reader needs to know the logical reading order and text alternatives. The ISO therefore defined profiles: subsets of PDF that forbid certain things and make others mandatory. A PDF/X, PDF/A or PDF/UA is still a valid PDF – but one that follows additional rules.

PDF/A – for long-term archiving

PDF/A (ISO 19005) is the format for documents that must remain faithfully reproducible for decades. The core idea: the file must be self-sufficient and contain everything needed for correct display.

  • All fonts must be embedded.
  • Colors are described device-independently via ICC profiles.
  • Encryption, JavaScript and external references are forbidden.
  • XMP metadata is mandatory.

There are versions PDF/A-1 to A-4 (2005 to 2020) as well as conformance levels a, b and u. In Germany, PDF/A is especially relevant for GoBD-compliant, audit-proof archiving and for e-invoicing (ZUGFeRD/Factur-X, which builds on PDF/A-3). Because we already cover PDF/A in detail in its own article, we focus here on the two other standards.

PDF/X – for professional printing

PDF/X (ISO 15930) is the standard for exchanging print-ready data between design, publishing and print shops. The goal is reliability in the print process: what the printer produces from the file should exactly match what the creator intended – no nasty surprises with colors or missing fonts.

Central requirements of PDF/X:

  • All fonts embedded – otherwise the print shop doesn't have them.
  • Defined target color space (output intent) – an embedded ICC profile describes which printing condition (e.g. paper and press) the file is designed for.
  • No RGB in the strict profiles – printing works with CMYK and spot colors.
  • No JavaScript, no forms, no encryption.
  • Defined page boxes such as MediaBox, TrimBox and BleedBox – so bleed and final format are unambiguous.

The main variants differ mostly in how they handle color and transparency:

VariantISOColorTransparency
PDF/X-1a15930-1CMYK + spot colors only, no RGBnot allowed (must be flattened)
PDF/X-315930-3additionally color-managed RGB/Lab with ICCnot allowed
PDF/X-415930-7like X-3, ICC output profileallowed (live transparency) + layers

PDF/X-1a is the most restrictive and oldest widely used profile: pure CMYK, no transparency, maximum compatibility with legacy workflows. PDF/X-3 additionally allows color-managed RGB that is only converted to the target color space at print time. PDF/X-4 (based on PDF 1.6) is the modern standard: it allows real, non-flattened transparency and layers (optional content), which considerably simplifies data exchange from modern layout programs. If a print shop doesn't mandate a specific profile, PDF/X-4 is usually the right choice today; older or very conservative shops still ask for PDF/X-1a.

PDF/UA – for accessibility

PDF/UA (ISO 14289, "UA" for Universal Accessibility) is the standard for accessible PDF documents. It ensures that assistive technologies such as screen readers can correctly interpret and read out a document. Visually, a PDF/UA document looks like any other PDF – the difference lies in the structure beneath the surface.

The core of PDF/UA is the tagged PDF (based on PDF 1.7): above the visible rendering sits a logical structure tree describing what is a heading, paragraph, list, table or image. Key requirements:

  • Complete, correct tag structure with meaningful semantics.
  • Defined reading order that is correct independently of the visual layout.
  • Text alternatives for images and graphics.
  • Language declaration for the document (and, where needed, individual passages).
  • Distinction between real content and pure decoration (artifacts), so the screen reader skips decorative elements.

PDF/UA is closely related to the Web Content Accessibility Guidelines (WCAG), but concretely defines how those principles are to be implemented technically in a PDF. Conformance is checked using the Matterhorn Protocol published by the PDF Association, which translates the requirements into machine-checkable and manually checkable points.

Its practical importance is rising sharply: the European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025 and obliges many businesses to provide digital products and documents accessibly; in Germany it is implemented as the Barrierefreiheitsstärkungsgesetz (BFSG). For public bodies, BITV 2.0 has additionally applied for years. Accessible PDFs are therefore no longer optional for many organizations, but mandatory.

The direct comparison

FeaturePDF/APDF/XPDF/UA
ISO standard190051593014289
Purposelong-term archiveprepressaccessibility
Fonts embeddedrequiredrequiredrequired
Color managementICC profilesoutput intent (target color space)not a focus
Tag structureonly at level Anot requiredmandatory
Transparencyallowed from A-2only X-4allowed
JavaScript / encryptionforbiddenforbiddenrestricted

Can one PDF meet several standards at once?

Yes – and in practice this is often desirable. The profiles don't fundamentally exclude each other; they combine as long as the strictest rules of each are met. The most natural combination is PDF/A-2a or A-3a with PDF/UA: PDF/A conformance level "a" already requires a tagged structure, which is needed for PDF/UA anyway. Such a document is therefore both archive-ready and accessible.

PDF/X and PDF/A can also be combined within limits, because both require embedded fonts and defined color management. A pure print PDF (PDF/X) and an accessible document (PDF/UA), by contrast, have different priorities: in printing the tag structure is irrelevant, in accessibility the target color space is. Here you choose by intended use.

In practice: creating and checking

One point is often underestimated: a document doesn't become conformant "by accident". On export from Word, InDesign, LibreOffice or a PDF tool, the desired profile must be actively selected, and the software must enforce the rules – embed fonts, set the color profile, remove forbidden elements like JavaScript or flatten transparency. Whether the result really meets the standard is pure hope without a check.

That's why every serious workflow includes a preflight or validation step. For PDF/A, the open-source veraPDF has established itself as the reference; it checks a file against the exact ISO clauses and reports every violation. For PDF/X, preflight profiles in layout and prepress programs take on this role and additionally check print-specific things like resolution, bleed and overprinting. For PDF/UA, technical conformance can partly be tested automatically (e.g. along the Matterhorn Protocol), but the substantive correctness of reading order and text alternatives remains a manual review task. The rule of thumb: validate first, then send or archive.

Other PDF standards on the sidelines

The family is even larger. For completeness:

  • PDF/E (ISO 24517) – for technical and engineering documents, including 3D data.
  • PDF/VT (ISO 16612-2) – for variable data printing (personalized mailings, transactional print), building on PDF/X-4.
  • PDF/H – a best-practice approach for healthcare documents (never finalized as its own ISO standard).

For the vast majority of users, though, PDF/A, PDF/X and PDF/UA remain the three decisive ones.

Frequently asked questions

Does a PDF automatically become a PDF/A or PDF/X?

No. The conformance profile must be actively selected on export, and the tool must enforce the rules (embed fonts, set the color profile, remove forbidden elements). Whether the file is really conformant is best checked with a validator – for example the open-source veraPDF for PDF/A, or preflight tools for PDF/X.

Which profile does my print shop require?

Ask specifically. Many shops mandate PDF/X-4 or PDF/X-1a and additionally name the desired output-intent profile (e.g. a particular paper/printing condition). Without this information, even a technically correct PDF/X can end up off in terms of color.

Is a tagged PDF enough for accessibility?

Tags are the foundation, but not automatically sufficient. A document is only truly accessible once reading order, text alternatives, language and semantics are correct. PDF/UA defines exactly these requirements; automatic "make PDF accessible" buttons often only provide a starting point that needs manual rework.

Is a PDF/X smaller or larger than a normal PDF?

Tends to be slightly larger, because all fonts and the color profile must be embedded. The difference is usually small and negligible in a print context – reliability matters more here than file size.

Conclusion

PDF is a container with many faces. If you know what a document is meant for, you pick the right profile: PDF/A for archiving and legal certainty, PDF/X for reliable printing, and PDF/UA for accessibility. The three standards don't fundamentally contradict each other; they set different priorities – and in cases like PDF/A-2a + PDF/UA they can even be sensibly combined. What matters is to set the profile deliberately when creating the file and then validate it, rather than assuming that "a PDF is just a PDF".

Convert documents with wandlio

Around PDFs and documents at wandlio:

Document conversions run server-side, and your file is always deleted afterwards.