PDF Format Types Explained: When to Use PDF/A, PDF/X, PDF/UA, and PDF/E

<p>A standard PDF file is a container format with very few mandatory constraints on content. It can embed fonts or rely on system fonts. It can include JavaScript. It can reference external files. It can use proprietary encryption. It can embed color profiles or ignore them entirely. This flexibility makes standard PDF universally compatible with every PDF viewer and creator — and completely unreliable for the specific use cases where predictability is mandatory.</p><p>The ISO PDF sub-format standards solve this by adding restrictions rather than features. Each standard defines a subset of the PDF specification — a list of features that compliant documents must use or must not use — and provides a way to self-declare conformance inside the file's XMP metadata. This self-declaration is what allows automated compliance checking: archiving systems, preflight checkers, and accessibility validators can read the conformance declaration and verify that the document's actual content matches what it claims to be.</p><p>The four major specialized PDF standards address four distinct reliability problems:</p><p><strong>PDF/A</strong> addresses the long-term readability problem: standard PDFs rely on software, fonts, and color profiles that may not exist in 20 years. PDF/A eliminates external dependencies entirely so documents are self-contained and renderable without any software beyond a compliant PDF renderer.</p><p><strong>PDF/X</strong> addresses the print production reliability problem: standard PDFs produce inconsistent printed output because color spaces, font embedding, overprint settings, and bleed dimensions are not standardized. PDF/X defines exactly what a file must contain for a commercial printer to reproduce it accurately without re-processing.</p><p><strong>PDF/UA</strong> addresses the accessibility problem: standard PDFs are opaque to screen readers unless they contain specific structural tagging. PDF/UA requires complete tag structure, reading order, alt text for images, and language declarations that enable full assistive technology support.</p><p><strong>PDF/E</strong> addresses the engineering document problem: technical drawings require embedded 3D models, engineering metadata, and geospatial references that standard PDF supports but does not standardize. PDF/E defines the required encoding for these elements so documents transfer reliably across CAD systems.</p><p>Understanding which problem applies to your documents determines which standard applies. Most professionals need PDF/A for compliance and records management, PDF/UA when publishing accessible documents, and standard PDF for everything else.</p>

<p>PDF/A is defined by ISO 19005, first published in 2005 with subsequent parts published through 2020. It is the mandatory file format for long-term digital preservation in government records management, legal discovery, healthcare records retention, and financial regulatory compliance. The European Union mandated PDF/A-2 for government document archiving across all member states under the ETSI EN 319 162 technical specification. The US National Archives specifies PDF/A as one of two acceptable formats for permanent electronic records. Courts in the US, EU, Australia, and Canada require PDF/A for electronically filed legal documents with archival status.</p><p>PDF/A achieves permanent readability by prohibiting every PDF feature that depends on external software or resources. The standard's restrictions are extensive: no external content references, no encryption (archived documents must be accessible without passwords), no embedded JavaScript or executable code, no audio or video content, no transparency (some conformance levels), and no color data without embedded ICC color profiles. All fonts must be fully embedded — PDF/A documents cannot rely on system fonts, which may not be installed on the system opening the document in 2045.</p><p>PDF/A has four conformance levels across its three parts, each adding stricter requirements:</p><p><strong>PDF/A-1</strong> (ISO 19005-1, 2005): The original standard based on PDF 1.4. Two levels: PDF/A-1b (basic conformance — visual appearance only) and PDF/A-1a (full conformance — visual appearance plus logical structure for accessibility). Most enterprise document management systems that predate 2010 accept only PDF/A-1.</p><p><strong>PDF/A-2</strong> (ISO 19005-2, 2011): Based on PDF 1.7. Permits JPEG2000 compression (30–50% smaller files than PDF/A-1), allows embedding of compliant PDF/A-1 or PDF/A-2 files as attachments, and permits optional content (layers). PDF/A-2 is the current recommended standard for new archiving workflows. Three levels: PDF/A-2b (basic), PDF/A-2u (unicode, required for text searchability), and PDF/A-2a (full accessibility conformance).</p><p><strong>PDF/A-3</strong> (ISO 19005-3, 2012): Identical to PDF/A-2 but permits embedding any file format as an attachment — not just other PDFs. This enables hybrid workflows where a PDF/A-3 invoice contains its original XML source data (ZUGFeRD format, Factur-X) as an embedded attachment. Germany's ZUGFeRD e-invoicing standard and France's Factur-X standard both require PDF/A-3.</p><p><strong>PDF/A-4</strong> (ISO 19005-4, 2020): Based on PDF 2.0. Removes the distinction between conformance levels (a, b, u) and adds support for digital signatures with long-term validation (LTV). Required by some EU electronic signature regulations for archival-quality signed documents.</p><p>Creating a valid PDF/A file requires either a creation tool that natively outputs compliant files (Adobe Acrobat, LibreOffice with PDF/A export enabled, Word 2016+) or a conversion tool that converts existing PDFs to PDF/A compliance. Standard PDF-to-PDF/A conversion requires embedding fonts, adding ICC color profiles, stripping prohibited features, and writing the conformance declaration to the XMP metadata block. This conversion process commonly increases file size by 5–15% due to font embedding and ICC profile addition.</p>

1. 1Identify which PDF/A level your organization or regulation requiresCheck the specific requirement: court e-filing rules, your DMS software documentation, or regulatory guidance. Most current requirements accept PDF/A-2b as the minimum. If the document needs to be text-searchable (not just visually reproducible), require PDF/A-2u. If you need embedded attachments for hybrid invoicing, use PDF/A-3.
2. 2Export to PDF/A directly from the source applicationThis is more reliable than converting an existing standard PDF. In Microsoft Word 2016+: File → Save As → PDF → Options → ISO 19005-1 compliant (PDF/A). In LibreOffice: File → Export as PDF → check Archive (PDF/A-1a). In Adobe Acrobat: File → Save As → More Options → PDF/A-1b or 2b. Source application export embeds fonts and color profiles at creation, avoiding post-conversion issues.
3. 3Validate compliance before submitting or archivingUse an online PDF/A validator (veraPDF is the official ISO reference implementation, free at verapdf.org) or Adobe Acrobat's Preflight function. Validators catch issues that creation tools sometimes miss: un-embedded fonts added via system substitution, transparency not fully flattened, external URI references in metadata. Fix any reported issues before submission.
4. 4For existing PDFs, use a PDF/A converterTools like Adobe Acrobat's PDF/A conversion, Ghostscript with PDF/A output parameters, or commercial converters (PDF Tools AG, Nitro) convert existing PDFs to PDF/A. Note that Ghostscript's PDF/A output requires specific command flags and does not always catch all non-conformance issues — always validate the output independently after conversion.

<p>PDF/X is defined by ISO 15930 and covers the exchange of final-form print-ready files between content creators and commercial print service providers. The standard eliminates the most common causes of print production failures: missing fonts, wrong color spaces, missing bleed, incorrect overprint settings, and missing output intent profiles. PDF/X is universally required by commercial printers, packaging producers, newspaper publishers, and magazine publishers worldwide.</p><p>The standard exists because a standard PDF file contains insufficient information for reliable print reproduction. Color is the primary issue: a standard PDF can contain colors in RGB (optimized for screens), CMYK (optimized for print), device-independent Lab, or completely undefined device color spaces, mixed in any combination. A commercial print operation running a 4-color offset press requires CMYK input — RGB content must be converted to CMYK before the plate is made, and the conversion algorithm used dramatically affects how the printed colors look. PDF/X solves this by requiring a declared output intent profile that specifies exactly how colors should be interpreted and any necessary conversion applied.</p><p>PDF/X has several published versions, each adding capabilities:</p><p><strong>PDF/X-1a</strong> (ISO 15930-1, 2001): The strictest standard. All colors must be CMYK or spot colors — RGB, Lab, and ICC profiles are prohibited. All fonts must be embedded. No transparency (transparency must be flattened before creating the PDF/X-1a file). This standard is used by newspapers (SNAP standard uses PDF/X-1a), magazines, and advertisers who deliver to multiple publishers and need guaranteed consistency across all printing environments.</p><p><strong>PDF/X-3</strong> (ISO 15930-3, 2002): Extends PDF/X-1a to allow device-independent colors (Lab, ICC profiles) in addition to CMYK/spot. This permits color-managed RGB workflows for photographers and designers who work in RGB but need print-ready output. PDF/X-3 requires an output intent profile that the printer uses to convert device-independent colors to press-specific CMYK.</p><p><strong>PDF/X-4</strong> (ISO 15930-7, 2008): The current standard for modern print workflows. Based on PDF 1.6. Adds live transparency support (no pre-flattening required), optional content (layers), and JPEG2000 compression. PDF/X-4 is the default standard for commercial printing delivered to printers using PDF-based workflows (Agfa, Creo, EFI, Heidelberg). If you are sending files to a commercial printer today and they have not specified otherwise, PDF/X-4 is the correct choice.</p><p><strong>PDF/X-6</strong> (ISO 15930-9, 2021): Based on PDF 2.0. Adds support for multiple output intents for multi-channel printing and requirements for newer color space technologies.</p><p>For most business users — printing marketing materials, business cards, brochures, or signage through an online print service — the printer will specify their required PDF/X version. Canva, Vistaprint, and Moo print services all accept PDF/X-4. Submitting a standard RGB PDF to a commercial printer instead of PDF/X commonly results in colors that appear 15–25% darker and less saturated than they appeared on screen, because RGB-to-CMYK conversion without a specified output intent uses generic conversion parameters that do not match the actual press characteristics.</p>

<p>PDF/UA (Universal Accessibility) is defined by ISO 14289-1, published in 2012 and updated in 2014. It specifies the technical requirements for PDF files to be fully usable by people with disabilities — including those using screen readers, refreshable Braille displays, keyboard navigation without mouse, and voice control software. PDF/UA is required by law in many jurisdictions: the US federal government's Section 508 of the Rehabilitation Act, the European Union's Web Accessibility Directive (EN 301 549), and Australia's Disability Discrimination Act all require PDF/UA conformance for PDFs published on government, educational, and large-enterprise websites.</p><p>A standard PDF that was not created with accessibility in mind is essentially an image to a screen reader — the text is visually rendered but has no semantic structure that software can interpret. A screen reader reading an untagged PDF reads text in the order it appears in the PDF's internal content stream, which rarely matches the logical reading order of the document. Column layouts are read across both columns word by word rather than column by column. Tables have no row or column header associations. Images have no descriptions. Headings cannot be navigated. Form fields have no labels associated with them.</p><p>PDF/UA requires solving these problems through complete structural tagging:</p><p><strong>Tag structure</strong>: Every content element must be tagged with its semantic type — paragraph, heading level (H1–H6), list, table, figure, caption, footnote, form field. No content element can be untagged. Decorative elements (dividing lines, backgrounds) must be marked as artifacts to exclude them from the accessibility tree.</p><p><strong>Reading order</strong>: The tag order must reflect the logical reading order — top to bottom, left column before right column, before-body content before after-body content. This is independent of the visual layout, which can present content in any order regardless of the underlying tag sequence.</p><p><strong>Alternative text</strong>: Every figure (image, chart, graph, diagram) must have alternative text that describes the content for screen reader users. Charts must have alt text that conveys the data being shown, not just the type of chart. Decorative images must be marked as artifacts with empty alt text.</p><p><strong>Language declaration</strong>: The document must declare its primary language in the document catalog (e.g., <code>en-US</code>). Text in a different language from the document's primary language must have its language tagged at the element level so screen readers can switch pronunciation rules.</p><p><strong>Accessible form fields</strong>: PDF forms must associate field labels with their input fields using tooltip text and proper tagging so screen readers announce both the label and the expected input when focusing on a form field.</p><p>Creating PDF/UA conformant documents is most efficient when starting from properly structured source documents. A Word document with correctly applied heading styles (Heading 1, Heading 2), properly described images (right-click → Edit Alt Text), and a language declaration exports to a PDF that is close to PDF/UA compliant. Complete compliance typically requires finishing in Adobe Acrobat Pro's accessibility checker, which identifies and allows fixing remaining issues — reading order corrections, tag type adjustments, artifact markup — that Word's export does not fully automate.</p>

1. 1Structure your source document with proper heading stylesIn Word or Google Docs, apply Heading 1, Heading 2, Heading 3 styles to all headings — do not create visual headings by manually bolding and enlarging body text. These structural styles map directly to H1–H6 tags in the exported PDF, which screen readers use for navigation. A document with properly applied heading styles is 70% of the way to PDF/UA conformance before any PDF-specific work.
2. 2Add alt text to all images and chartsIn Word: right-click each image → Edit Alt Text → write a description that conveys what the image shows, not just what it is. A pie chart showing quarterly revenue by product line needs alt text like 'Pie chart showing Q1 2026 revenue: Product A 42%, Product B 31%, Product C 27%' — not 'Chart showing revenue data.' For decorative images (dividers, borders), mark alt text as decorative.
3. 3Export with accessibility settings enabledIn Word: File → Save As → PDF → Options → check Document structure tags for accessibility and ISO 19005-1 compliant (to also make it PDF/A-1a, which satisfies many accessibility requirements simultaneously). In Adobe InDesign: Export PDF → Tags → check Create Tagged PDF. In LibreOffice: File → Export as PDF → check Tagged PDF.
4. 4Run an accessibility check on the exported PDFOpen in Adobe Acrobat (Pro or free reader) → View → Show/Hide → Navigation Panes → Accessibility. Run the Full Check. Review flagged items: missing alt text, reading order issues, untagged content. Fix issues using the Tags panel (Pro only) or the Reading Order tool. For critical compliance requirements, use PAC 2024 (free, veraPDF-based) for comprehensive PDF/UA validation.

<p>PDF/E is defined by ISO 24517-1, published in 2008, specifically for engineering document exchange. It addresses the requirements of technical drawings, CAD-derived documents, and geospatial maps that need to embed 3D models, engineering metadata, and measurement data in a way that survives transfer across different engineering software environments.</p><p>Standard PDFs exported from CAD software (AutoCAD, SolidWorks, CATIA, Revit) can contain 3D models, annotations, measurement overlays, and rich engineering data — but the encoding of this data in standard PDFs is not standardized, meaning the same 3D content embedded by AutoCAD may not render correctly in a PDF viewer that was not specifically tested with AutoCAD exports. PDF/E standardizes the encoding of these elements so any ISO 24517-compliant viewer renders them consistently.</p><p>PDF/E requirements include: no external content dependencies (like PDF/A), embedded 3D models must use the U3D or PRC format (both specified in ISO standards), geospatial annotations must follow the ISO 32000 geographic coordinate system conventions, and the document must contain engineering metadata including revision tracking, drawing number, and project identification in the XMP metadata block.</p><p>PDF/E is primarily used in aerospace, defense, automotive manufacturing, and construction (AEC — Architecture, Engineering, Construction). The US Department of Defense's MIL-STD-31000B technical data package specification references PDF/E for engineering drawings. NATO STANAG 4575 for technical data management references PDF/E. Major aerospace prime contractors (Boeing, Airbus, Lockheed Martin) require PDF/E for supplier technical documentation.</p><p>For most professionals outside of technical engineering disciplines, PDF/E is not applicable. The other three standards — PDF/A, PDF/X, and PDF/UA — cover the document types encountered in business, legal, government, publishing, and educational contexts where compliance is most commonly required.</p>

<p>Choosing the correct PDF format requires matching the document's purpose and destination to the standard designed for that use case. Most professional PDF use cases fall into one of five categories.</p><p><strong>You are archiving documents for long-term retention</strong> — HR records, financial statements, contracts, legal filings, government records, healthcare records: use <strong>PDF/A-2u</strong> as the default. The 'u' conformance level ensures text is Unicode-mapped for full-text searchability, which matters when searching through archived documents years later. If your document management system specifies a different conformance level, follow the system requirement.</p><p><strong>You are sending files to a commercial printer</strong> — brochures, business cards, marketing materials, packaging, signage: use <strong>PDF/X-4</strong> unless the printer specifies otherwise. PDF/X-4 supports modern transparency effects (shadows, gradients, glows) without pre-flattening, handles both CMYK and ICC-profiled colors, and is accepted by all current commercial print workflows. Ask the printer for their ICC output intent profile and embed it in the PDF before submitting.</p><p><strong>You are publishing PDFs on a government, educational, or enterprise website</strong> — public-facing reports, forms, policies, research publications: use <strong>PDF/UA-1</strong>. Legal requirements under Section 508 (US federal), EN 301 549 (EU), and equivalent national legislation mandate accessibility compliance for digitally published PDFs. Creating PDF/UA documents from properly structured sources adds 15–30 minutes of work per document but eliminates legal compliance risk and serves users with disabilities.</p><p><strong>You are creating engineering or technical drawings for exchange</strong> with supply chain partners, government contractors, or aerospace/defense clients: use <strong>PDF/E</strong> as specified by the applicable technical data standard. Check the specific program's technical data package requirements, as aerospace programs often specify PDF/E conformance level and additional metadata requirements beyond the base standard.</p><p><strong>You are sharing documents for everyday business use</strong> — email attachments, reports, presentations, invoices for standard recipients, internal documents: use <strong>standard PDF</strong>. The specialized formats add requirements (font embedding requirements, format restrictions, additional metadata) that impose unnecessary overhead when documents are not archived long-term, not printed commercially, not subject to accessibility law, and not used in engineering contexts. Standard PDF with compression applied via <a href='/en/compress'>LazyPDF's compressor</a> is the correct choice for routine business document exchange.</p><p>A common misconception is that all important documents should use PDF/A. PDF/A restrictions — particularly the prohibition on encryption and JavaScript — make it unsuitable for documents that need password protection, interactive forms with calculated fields, or embedded video. Use PDF/A only where long-term archival is the explicit requirement. For protected documents, use standard PDF with password protection via <a href='/en/protect'>LazyPDF's protect tool</a>.</p>

1. 1Determine the document's primary destinationAsk: Is this document being archived for years or decades? Being sent to a commercial printer? Being published on a website subject to accessibility law? Being exchanged in an engineering supply chain? If the answer to all four is no, standard PDF is correct. If yes to one, use the corresponding standard: PDF/A, PDF/X, PDF/UA, or PDF/E.
2. 2Check for specific compliance requirements before creatingCourt e-filing rules, regulatory submissions, grant applications, and government portals often specify the exact PDF/A conformance level required (PDF/A-1b, PDF/A-2u, etc.). Check before creating, not after — converting an existing PDF to a specific conformance level is possible but more error-prone than creating correctly from the source.
3. 3Use source application export rather than post-conversion when possibleExporting to the specialized format directly from Word, InDesign, or AutoCAD is more reliable than converting an existing standard PDF. Source exports embed fonts and structural elements at creation. Post-conversion tools — Ghostscript, Acrobat conversion, third-party converters — sometimes miss edge cases that create technically non-conformant files that pass superficial checks but fail rigorous validators.
4. 4Validate every compliance-critical PDF before submittingFor PDF/A: use veraPDF (free, verapdf.org) — the official ISO reference validator. For PDF/X: use Adobe Acrobat's Preflight with PDF/X-4 profile or PitStop (commercial). For PDF/UA: use PAC 2024 (free) or Adobe Acrobat's accessibility checker. Never assume a document is compliant based on the export tool's success message — validate independently.