PDF to HTML Conversion Spec Updated to v1.2: What Changed

Put version 1.0 and version 1.2 of the PDF Association’s Deriving HTML from PDF side by side and the same small edit keeps appearing. In the subtitle, in the definition of derivation, in the definition of a processor, in the title of the clause that holds the algorithm itself. Each time, the word “tagged” has become “Well-Tagged”.

That is the release. The mapping rules got longer and the examples got sharper, but the change worth your attention is to what the algorithm assumes is arriving at the door.

The specification is quite unsentimental about files that miss the new bar. Scope allows derivation of a non-conformant PDF only when you account for the gap between the way the file was actually built and Well-Tagged PDF (WTPDF)’s provisions. Otherwise, it says, the results are unpredictable.

What changed between version 1.0 and version 1.2?

The expected input.

Version 1.0, published June 2019, defined derivation as the deterministic conversion of Tagged PDF files. Version 1.2, published September 2026, defines it as the deterministic conversion of Well-Tagged files, meaning files conforming to WTPDF, the PDF Association’s 2024 specification for tagging in PDF 2.0.

Version 1.1 was never published and served only as an internal transition point.

Beyond the input, the differences worth knowing:

	Version 1.0 (June 2019)	Version 1.2 (September 2026)
Expected input	Tagged ISO 32000-2 (PDF 2.0) files	Well-Tagged PDF, which is PDF 2.0 only
Orientation	A baseline derivation specification	A usage specification oriented to WTPDF and PDF 2.0
Emphasis	Layout extraction	Semantic conversion, with structured authoring, namespace-aware processing and processor behavior
Pagination	Handled less explicitly	Page breaks and page labels represented as HTML navigation
Math	MathML carried through associated files	Also a math structure element in the MathML namespace, with Alt becoming the alttext attribute
ARIA and forms	Less detailed	ARIA roles and attributes, form semantics and interoperable element mapping

Why does the expected input matter more than the mapping rules?

Because version 1.0 was written before Well-Tagged PDF existed. Both releases take PDF 2.0 (ISO 32000-2) files, so the file format has not moved at all. Just the standard of tagging the algorithm assumes it will find inside.

In 2019 that standard was tagged. Now it is Well-Tagged, a conformance level the PDF Association published in February 2024. Anything tagged before then was tagged with no such definition to work to, however carefully the work was done.

Those files will still go through a converter. What they lose is the guarantee. Derivation is defined as a deterministic process, which is the promise that the same file produces the same HTML every time, in any conforming processor. Hand a processor something it was not specified against and determinism is the first thing to go.

So the question is not whether your files are PDF 2.0 (the entry ticket since 2019). It is whether they are Well-Tagged or only tagged plain, and a checker score will not tell you which.

One shortcut is worth knowing. PDF/UA-2’s file format requirements are identical to WTPDF’s conformance level for accessibility, so PDF 2.0 files already built to PDF/UA-2 clear the bar for both. PDF/UA-1 files are a different matter, since they sit on PDF 1.7, which was outside this algorithm’s scope, both in 2019 and now.

What does version 1.2 say about accessibility?

That a conformance claim does not travel. Annex D states plainly that derived HTML should not be expected to be as accessible as the PDF it came from, and that a conformance level in HTML metadata should not be expected to come from the PDF’s declaration.

It then places the work with the author. Achieving accessible HTML is the author’s responsibility, met by structuring the PDF so the derived HTML conforms to HTML accessibility standards, and by providing HTML and ARIA structure attributes that are carried through into the output.

Read it without flinching, since that retires a comfortable assumption. A PDF/UA badge on the source file says nothing about the page your readers actually land on.

If conversion is still an open question for your team, the case for converting PDF to HTML for accessibility is worth reading alongside this.

What should teams check before their files reach a version 1.2 processor?

Find out what is Well-Tagged, not just tagged. This is the gate, and everything else sits behind it. PDF 2.0 files already conforming to PDF/UA-2 clear it. Files that merely pass a tagging checker may not, and most libraries have never been audited for the difference.
Tag for derivation, not only for conformance. Scope says the best results come when files are both authored and created with derivation to HTML in mind. Passing a checker and deriving cleanly are different tests, and a file can pass the first while failing the second.
Carry ARIA through the source. Annex D names this as the mechanism. An attribute that is not in the PDF cannot appear in the HTML, however good the processor is.
Judge the HTML on its own terms. Test the derived page with assistive technology against HTML accessibility standards, not against the conformance claim on the file it came from.

How Documenta11y helps

Documenta11y works on the input side, which is the side you control. That means establishing which of your files are Well-Tagged and which are only tagged, remediating to Well-Tagged PDF rather than to a checker score, and treating the derived HTML as a deliverable in its own right rather than as a by-product.

Automated tagging produces a file that passes. Expert review produces a file that derives. Version 1.2 made the gap between those two outcomes matter more than it used to. Talk to us about a tag-quality check on your library before a PDF to HTML conversion gets built on top of it.

Frequently asked questions

Is the Deriving HTML from PDF specification mandatory?

No. It is a PDF Association usage specification, not an ISO standard and not a regulation. It carries weight because it is written for the developers who build converters, and Scope says so directly, which makes it the working description of what your files turn into.

Does version 1.2 replace PDF/UA?

No. PDF/UA-2 sets accessibility requirements for the PDF itself. Version 1.2 describes how a Well-Tagged PDF becomes HTML. WTPDF’s accessibility conformance level and PDF/UA-2 share the same file requirements, so a file built to one is built to the other.

Can tagged PDFs be converted into accessible HTML?

Tagged is no longer the bar. Well-Tagged is. A conforming file gives the algorithm predictable input, but Annex D is explicit that accessible HTML still has to be achieved on purpose, through structure and ARIA attributes carried from the source.