Every PDF contains two layers. The first is the content stream: the drawing instructions that tell a viewer where to place each glyph, each line, each image on the page. This layer produces what you see. The second, when it exists, is the tag tree: a hierarchical structure of labeled elements that describes what the content means. A heading is marked as a heading, a table cell knows which row and column it belongs to, an image carries alternative text, and the reading order is explicitly defined rather than inferred from the position of characters on a page.
Most PDFs have the first layer. Most PDFs do not have the second. The distinction between those two states is the difference between a document that a screen reader can navigate and one that it cannot, between a document that a search engine can index meaningfully and one that it treats as an opaque file, between a document that an enterprise search system can query by structure and one that it can only scan by raw character matching.
What's Trapped
When a PDF lacks tags, the document's meaning is locked inside its visual appearance. A sighted reader infers structure from layout: larger text is probably a heading, items arranged in rows and columns are probably a table, a block of smaller text at the bottom is probably a footnote. Assistive technology cannot make those inferences. It reads the content stream in the order the characters were drawn, which may bear no relationship to the order a human would read them, and it has no way to distinguish a heading from a paragraph, a table cell from a floating text box, or an image from an empty space.
What a Tag Tree Looks Like
A tag tree is a hierarchy of structural elements, conceptually similar to the Document Object Model (DOM) of a HyperText Markup Language (HTML) page. The root element (typically <Document>) contains sections, which contain headings, paragraphs, lists, tables, and figures. Each element in the tree maps to a region of the content stream, connecting the "what it looks like" layer to the "what it means" layer.
The tag types follow the PDF techniques documented by W3C WAI and align closely with HTML semantics. <H1> through <H6> mark headings at different levels. <P> marks paragraphs. <Table>, <TR>, <TH>, and <TD> define table structure. <Figure> marks images, with an /Alt attribute providing alternative text. <L>, <LI>, <Lbl>, and <LBody> define lists. The correspondence is not accidental; it reflects the fact that both HTML and tagged PDF are trying to solve the same problem, which is to separate what content looks like from what it means.
What Tags Enable
The tag tree unlocks four capabilities that untagged PDFs cannot provide.
Screen reader navigation
A screen reader user navigating a tagged PDF can jump between headings, move through table cells by row and column, skip decorative images, and hear the reading order as the author intended. Without tags, the screen reader processes the content stream in drawing order, which in a two-column layout may mean reading halfway across the first line of column one, then jumping to the first line of column two, then back to column one. The result is unintelligible.
Reflow and text extraction
When a tagged PDF is reflowed (resized to fit a smaller screen), the tag tree determines the order in which content rearranges. Headings remain headings, paragraphs stay together, and table structure is preserved. Adobe's reflow documentation explains that Acrobat may temporarily tag untagged files before reflowing them, which is useful but unreliable compared with author-supplied structure. Text extraction for search indexing, copy-paste, and large language model (LLM) ingestion is similarly dependent on tags: without them, extracted text may arrive in an order that reflects the drawing sequence rather than the reading sequence.
Structured search and document intelligence
Enterprise search systems that index tagged PDFs can query by structure: "find all tables in budget documents" or "extract the executive summary from every annual report." Untagged PDFs offer only full-text search against the raw character stream, with no structural context. As organizations invest in document intelligence and retrieval-augmented generation systems, the distinction between a tagged document (which preserves its own semantics) and an untagged one (which does not) becomes an infrastructure-level concern.
Regulatory compliance
Section 508 of the Rehabilitation Act requires federal electronic content to conform to accessibility standards. The European Accessibility Act (EAA), which has applied since 28 June 2025, applies accessibility requirements to covered products and services across the European Union. The PDF/Universal Accessibility (PDF/UA) standard defines the technical requirements for accessible PDFs, and its central requirement is a complete, correct tag tree. The careful statement is this: an accessible PDF needs tags, even when an organization may also satisfy a service obligation by publishing an accessible HTML equivalent.
Untagged PDF
Screen reader reads in drawing order
No heading navigation
Tables read as a stream of text
Images are invisible or unlabeled
Reflow produces unreadable layout
Search extracts fragmented text
Tagged PDF
Screen reader follows reading order
Jump between headings by level
Navigate table cells by row/column
Images carry alternative text
Reflow preserves document structure
Search indexes by structural context
How Tags Are Created
Tags originate in the authoring application, and the most common point of failure is that the authoring application either does not create them or creates them incorrectly.
Microsoft Word
Word documents that use built-in heading styles (Heading 1, Heading 2, etc.) and proper list formatting will, when exported to PDF using "Save as PDF" with the "Document structure tags for accessibility" option enabled, produce a tagged PDF with a reasonable tag tree. The operative phrase is "built-in styles": a document formatted by selecting text and manually changing its font size to 18 points, making it bold, and calling it a heading has no structural information for the export to preserve. The text looks like a heading to a sighted reader, yet Word's PDF export has no way to know it is one, because the author never told Word it was one.
Adobe InDesign
InDesign has the most sophisticated PDF tagging support of any desktop publishing application, including the ability to map paragraph styles to PDF tags, define reading order through the Articles panel, and set alternative text on placed images. The problem is that most InDesign users do not know these features exist, because InDesign's default workflow does not surface them. An InDesign user who creates a visually polished document and exports it to PDF without visiting the Articles panel or the Tags panel will produce a PDF with either auto-generated tags (which are frequently wrong, particularly for complex layouts) or no tags at all.
Scanned documents
A scanned PDF (a document created by photographing paper pages) contains only images. It has no text layer at all until Optical Character Recognition (OCR) software adds one, and even then, the OCR layer provides only raw text without structural information. Converting a scanned document into a properly tagged PDF requires two separate processes: OCR to create the text layer, and manual or semi-automated remediation to create the tag tree. The first is largely automated; the second is labor-intensive, error-prone, and expensive, which is why remediation firms typically charge per page and why a 400-page scanned annual report can cost several thousand dollars to remediate.
Web-to-PDF conversion
Browser "Print to PDF" functions and most web-to-PDF conversion tools strip the semantic structure of the source HTML. An HTML page with well-formed headings, labeled form fields, and proper table markup will, when printed to PDF through a current Chromium-based browser, carry a tag tree derived from the page accessibility tree, including headings, tables and alternative text. Chrome has done this since version 85. Older browsers, and many desktop applications printing through a generic PDF driver, still produce untagged output that preserves the visual appearance while discarding the structure, so tagging cannot be assumed without checking the file. The tag tree is either absent or auto-generated from the visual layout, which consistently misidentifies headers, merges table cells, and assigns incorrect reading order to multi-column content.
Author
Use built-in styles
Export
Tags often lost here
Convert
Print-to-PDF strips structure
Publish
Tags present or absent
How to Check Whether a PDF Is Tagged
Checking whether a PDF is tagged takes less than ten seconds, and the method depends on which tool you have available.
Adobe Acrobat Pro: Open the document, then navigate to File > Properties. The Description tab will show a "Tagged PDF" field that reads either "Yes" or "No." For a deeper inspection, open the Tags panel (View > Show/Hide > Navigation Panes > Tags), which displays the full tag tree. If the Tags panel is empty, the document has no tags.
Adobe Acrobat Reader (free): File > Properties > Description > "Tagged PDF: Yes/No." Reader cannot display or edit the tag tree, only confirm its presence.
PAC (PDF Accessibility Checker): The free PAC tool, developed and hosted by axes4 GmbH, runs a comprehensive accessibility check that includes tag validation. It reports whether the document is tagged, whether the tags are structurally correct, and whether they conform to the PDF/UA standard. PAC is the most thorough free validation tool available for PDF accessibility.
Command line: If you have access to a command-line environment with a PDF library (such as pdfinfo from Poppler or exiftool), you can check the Tagged metadata field programmatically. This is useful for auditing document libraries at scale: a script that checks the Tagged field across thousands of files can identify untagged documents in minutes.
Common Tag Tree Problems
A tagged PDF is not necessarily a correctly tagged PDF. The presence of a tag tree is a necessary condition for accessibility; it is not a sufficient one. The following problems share a common signature: each one produces a document that reports itself as tagged while failing in use.
Incorrect reading order
The tag tree defines the order in which a screen reader processes content. If the tags are ordered incorrectly (a common result of auto-tagging multi-column layouts), a screen reader may read the left column header, then the right column header, then return to the left column body text, producing a sequence that no human would follow. The visual layout looks correct; the structural reading order is wrong; the document is inaccessible.
Missing alternative text
Every <Figure> tag in the tree should carry an /Alt attribute containing alternative text that describes the image's content or purpose. Auto-tagging tools frequently create <Figure> tags for images without adding alternative text, which satisfies the structural requirement (the image is tagged) while failing the accessibility requirement (the image has no description). The tag tree is technically present yet functionally incomplete.
Flat heading hierarchy
A tag tree where every heading is tagged as <H1> (or, more commonly in auto-tagged documents, as <P> with no heading designation at all) destroys the document's navigational structure. Screen reader users rely on heading levels to understand the document's organization: an <H2> is a subsection of the preceding <H1>, and an <H3> is a subsection of the preceding <H2>. When all headings are the same level, or when headings are not tagged as headings at all, the document's hierarchy is invisible to assistive technology.
Table structure errors
Tables require header cells (<TH>) to be distinguished from data cells (<TD>), and complex tables require scope attributes or header-ID associations that specify which header applies to which cell. Auto-tagged tables almost never get this right for anything more complex than a simple grid, and the result is a table that a screen reader announces as a sequence of disconnected values with no indication of what each value represents.
Artifacts not marked
Decorative elements, page numbers, headers, footers, and watermarks should be marked as artifacts in the tag tree, which tells assistive technology to skip them. When these elements are tagged as content instead of artifacts, a screen reader will announce "Page 47" between every paragraph, read the running header at the top of every page as though it were part of the body text, and treat a decorative border as a meaningful figure.
PDF/UA: The Accessibility Standard for Tagged PDFs
PDF/UA (ISO 14289) is the international standard that defines what a properly tagged PDF looks like. It builds on the PDF specification's tagging capabilities and adds requirements that close the gaps auto-tagging tools typically leave open.
PDF/UA requires, among other things, that every document have a complete tag tree with no untagged content; that all images have alternative text or be marked as artifacts; that the tag tree's reading order match the logical reading order of the document; that tables have properly identified header cells; that the document's language be specified; and that all fonts be embedded so that text extraction produces correct characters rather than garbled output.
The standard is significant for two reasons. First, it provides a machine-testable specification: a document either conforms to PDF/UA or it does not, which makes automated compliance checking possible (the PAC tool mentioned earlier tests against this standard). Second, it occupies a specific and frequently overstated place in regulation. Section 508 references PDF/UA-1 once, at 504.2.2, as a requirement on authoring tools to be capable of exporting conforming files; its benchmark for the documents themselves, at E205.4, is WCAG 2.0 Level A and AA. Neither the European Accessibility Act nor the version of EN 301 549 currently in force names PDF/UA or ISO 14289 at all, and clause 10 of EN 301 549 sets requirements for non-web documents that parallel WCAG rather than pointing at PDF/UA. Conformance to PDF/UA remains the most practical route to satisfying those requirements for a PDF, which is a different and weaker claim than being the mandated benchmark.
What's Trapped
Most organizations that publish PDFs do not know whether their documents are tagged, have never opened a tag tree, and have no process for checking. The result is a document ecosystem where compliance is assumed rather than verified, where auto-tagging is treated as equivalent to proper tagging, and where the structural information that makes a document accessible, searchable, and machine-readable is absent from the majority of published files. The knowledge is not missing; the process is.
What to Do Next
If you publish PDFs, the minimum responsible step is to know which of your documents are tagged and which are not. The audit does not need to be comprehensive to be useful: checking the ten most-downloaded documents on your website will reveal whether your publishing pipeline produces tagged output or strips it.
If your documents are not tagged, the next step depends on their source. Documents authored in Word or InDesign can often be re-exported with tags by enabling the correct export settings and ensuring the source files use built-in styles. Scanned documents require OCR and manual remediation. Documents generated from web content or data systems may require changes to the generation pipeline.
If your documents are tagged, the next step is to verify that the tags are correct. The PAC tool will identify structural errors (wrong reading order, missing alt text, broken table headers) that the presence of tags alone does not reveal. A tag tree that exists only formally, with incorrect structure, missing attributes, or wrong reading order, provides a false sense of compliance while leaving the document inaccessible in practice.
The distinction matters more than it used to. Regulatory requirements are expanding, enterprise search systems increasingly depend on document structure, and retrieval systems built on top of documents can use tag structure where it exists, though we are not aware of a published study quantifying the effect on large language model performance. The tag tree is the infrastructure that connects a document to every system that needs to understand it, and building that infrastructure is cheaper at authoring time than at remediation time, which is cheaper than at litigation time.
The PDF specification (ISO 32000-2:2020) defines the tag types and structural requirements referenced in this article. PDF/UA (ISO 14289-2:2024) defines the accessibility conformance requirements. The PAC (PDF Accessibility Checker) tool is developed and hosted by axes4 GmbH and is freely available for download. Section 508 requirements reference the ICT Accessibility Standards (36 CFR Part 1194), which incorporate WCAG 2.0 Level AA by reference. No rulemaking to update that reference to a later WCAG version has been proposed. The European Accessibility Act (Directive 2019/882) has applied since 28 June 2025.