Executive summary
Public information now serves two audiences at once: the reader, and the systems that bring the reader to the content. Both read structure. HTML carries structure in the document itself, which is why browsers, search crawlers, AI retrieval systems, and assistive technologies can all read the same page and arrive at the same understanding of what it says.
Public-sector publishing policy in the UK and US, the web accessibility standards maintained by the W3C, and research into how modern search and AI systems retrieve content all point in the same direction. For public-facing guidance, policy, and reference material, structured HTML is the format best suited to the way public content is read, found, and acted on. This article sets out the positive case for HTML as the publishing default, the value it carries for readers and the systems that serve them, and what good HTML publishing looks like in practice.
WHY
Public information is only as useful as its reach. The format it is published in decides whether the public it was written for can find it, read it, and act on it.
Organisations responsible for public guidance and reference content now publish for two audiences at once. The first is the reader, who may arrive on a phone, through a screen reader, or in a language other than the document's original. The second is the machine that indexes the page, interprets its structure, and retrieves it for search and AI answer systems.
Both depend on content that carries its own meaning in a form they can read.
HOW
HTML carries meaning in the document itself. Headings, lists, tables, links, and image descriptions are part of the structure, not drawn on top of it. That is why a browser, a screen reader, a search crawler, and an AI retrieval system can all read the same page and arrive at the same understanding of what it says.
PDF was designed to preserve how a page looks when printed. Structure has to be added to it afterwards through tagging, and the tagging has to be correct, complete, and maintained over time. When that work is done well the result can be strong; when it is not, meaning lives in the visual layout and is lost to anyone or anything that cannot see the page.
WHAT
The recommendation that follows is consistent across public-sector publishing guidance in the UK and the US, across the web accessibility standards that govern inclusive publishing, and across research into how modern search and AI retrieval systems read content. Public-facing informational content should be published as structured HTML, with the authoring and conversion disciplines to produce it well embedded in the workflow that creates it.
Findability begins with structure
Search has always rewarded content that is well-structured. What has changed is how much structure now matters to the way content is ranked, displayed, and retrieved. HTML pages carry the signals that modern search depends on: page-level metadata, structured data, snippet control, descriptive titles, and the contextual cues that connect a page to the content around it.
These signals sit inside the HTML itself. A heading authored as a heading is read as a heading. A table authored with header cells is read as tabular data. An image with descriptive text is included in image search results and connected to the topic it supports.
Google's published guidance on file types indexable by Google confirms that most text-based files can be indexed. The same guidance, together with Google's introduction to structured data, describes how HTML supports ranking, rich results, and presentation in search features. The signals HTML carries are the signals search systems are built to read.
For organisations publishing guidance, policy, or reference material, the practical difference is direct. HTML pages participate on the same terms as other content across the web. The content is indexed, navigable, linkable, and visible to the systems that connect readers to the information they need.
The operational effect compounds across the web estate. An organisation with thousands of pieces of public guidance, consistently authored in HTML, produces a coherent, findable body of content. Readers looking for specific information arrive at the specific page that answers their question, and the content supports the path that brought them there.
Structured data adds a further layer of precision. Schema markup embedded in HTML pages describes what the content is, how it relates to other content, and what kind of result it should produce in a search listing. That precision carries directly into how a page appears in search results, and into the context the page brings with it when a search feature pulls an answer out of it. For organisations publishing reference content that readers need to act on quickly, that precision is part of the service.
AI answer systems read structured content
Public information is increasingly surfaced by AI answer engines. Generative AI systems retrieve and summarise public content, and the retrieval process they run is built around structured web pages.
Google's own guidance on AI features in Search describes how generative results draw on indexed web content. Microsoft's guidance for grounded AI responses in Copilot Studio describes the same workflow of retrieval, validation, and citation against indexed, crawlable public web content.
Research into document extraction supports the same point from the technical side. Benchmarks such as READoc and OmniDocBench, published in peer-reviewed research in 2024, show that extracting reliable structured meaning from PDFs remains an active area of research, with performance varying across document types.
HTML removes most of this work before it starts. The structure is already in the page. A retrieval system that reads an HTML page does not need to reconstruct the document to understand it; it reads what the markup already carries.
For organisations whose public information should appear in AI-generated answers, that starting point is consequential. Content published in HTML is ready to be read, chunked, cited, and surfaced. Guidance, policy, and reference material can be retrieved by the systems increasingly used to answer public questions.
The mechanics of retrieval reinforce the point. AI answer systems divide content into passages, match those passages to the query they are answering, and cite the source page back to the reader.
Passages that carry their own structural context, a heading above them, a list around them, or a table they belong to, give the retrieval system the material it needs to return accurate, attributed answers. HTML carries that context in the markup. Content produced this way is ready for retrieval at the point of publication, and stays ready as the underlying page is maintained.
Reach on any device, in any language, by any reader
Web content reflows. A page written once in HTML adapts to the screen it is read on, whether a phone held on a commute or a desktop in an office. The W3C's guidance on reflow describes why this matters: content that adapts to a single column is easier to read without horizontal scrolling, and remains readable when users increase text size to suit their eyesight.
The same property supports language. Browser-based translation tools operate on HTML at the text level, preserving structure while substituting language. Users who prefer to read in a language other than the original can do so within the page they arrived on, and the structure of the content stays intact as the words change.
Accessibility follows from the same foundation. WCAG 2.2, the web accessibility baseline maintained by the W3C, was written around web content and is supported natively by the HTML model. Screen readers use page structure to navigate; users who rely on keyboard input can move through content because the markup identifies what is interactive and what is not.
Public-sector publishing guidance reflects this. GOV.UK guidance on publishing accessible documents identifies HTML as the most accessible format for publishing documents and recommends it as the first choice. Its content design guidance sets out the same position for web content, identifying HTML as the format best suited to mobile devices and assistive technology. Section 508 guidance for US federal publishing describes HTML as the format best suited to inclusive web content and recommends it is used in preference to PDF wherever that is possible.
For local and municipal government decision-makers specifically, the practical implication is direct. Citizens interact with public services across a wide spread of devices, languages, and accessibility needs. HTML is the format that supports all three as native outcomes of well-authored content.
The reader's experience
The value of structured content shows up most clearly in the experience of using it. A reader arriving at a well-authored HTML page can skim the headings to find the section they need, follow a link to a related piece of guidance, copy a passage to share with a colleague, and return to the page on a different device with the content adjusting to the new screen.
Assistive technology users experience the same structure differently. Screen readers announce headings as landmarks, allowing the user to move through the page at the speed of their own reading rather than the speed of linear narration. Keyboard users tab through the interactive elements of the page in the order the content was authored. Users who resize text to suit their vision find the content staying readable as it scales.
For readers reaching public content under time pressure, in a second language, or on a shared device, that experience is the difference between useful information and a page they leave. HTML supports the behaviours readers actually use to get value out of the content they find.
One source, updated once
Public content changes. Guidance is refreshed, policy is updated, references are corrected, and contact details move. HTML content lives in a single published place, and a change made in that place is the change the reader sees.
The Government Digital Service, writing in its 2018 post Why GOV.UK content should be published in HTML and not PDF, set the practical case out directly. One HTML publication is easier to maintain than multiple versions of the same content in different formats. Links from HTML can be updated and audited, and content can be reused, extracted, and surfaced through APIs and content management systems.
That model turns publication from an event into an ongoing practice. When guidance moves, the page carrying it moves with it. Readers arriving afterwards see the current version, and the organisation holds a single record of what was said and when.
For digital and communications teams responsible for content estates running into thousands of pages, the operational benefit compounds. A coherent, well-structured HTML estate supports search, analytics, indexing, and redesign in ways that a distributed collection of document files cannot match at scale.
Engagement you can see and act on
HTML pages produce meaningful engagement data. Time on page, scroll depth, link-following, internal search terms, and return visits all contribute to a clear picture of how content is used. That picture turns content from an output into evidence of reach, effectiveness, and value.
The Government Digital Service's publishing guidance highlights this property of HTML directly. Content performance can be watched, understood, and improved. Pages that work well are identifiable, as are pages where readers stop short of finding what they came for.
For senior leaders accountable for the effectiveness of public information, that evidence matters. Publishing decisions can be made on data rather than assumption. Content investment can follow what the audience is using, and editorial priorities can be set on visible reader behaviour.
Governance, audit, and the public record
Public information lives under obligation as well as expectation. Organisations publishing guidance and policy need to know what was said, when it was said, and who approved it. HTML content sits inside a content management system that carries that history natively: version control, approval chains, publication dates, and revision records are part of the publishing surface.
This gives digital and policy leadership a governable estate rather than a distributed library of files. Content can be audited; changes can be traced; accessibility reviews can be run against the content as it stands; and publication decisions can be tied to the record of how the content reached the reader.
For organisations operating under public-sector accountability requirements, the governance case is practical and direct. HTML publishing produces a record the organisation can stand behind and an estate the organisation can demonstrate it is managing.
The quality of the content
The value any publishing format carries depends on how the content is authored within it. HTML rewards clear authoring: headings become navigation, lists become lists, tables carry the relationships between their cells, images carry descriptive alternative text, and links describe their destination. The W3C's page structure tutorial describes how each of these elements contributes to a page that is readable, navigable, and interpretable by the systems and technologies that serve the reader.
For publishing teams, the implication is that producing good HTML is a content-engineering practice rather than a formatting task. The work sits with the content itself: clarifying structure, identifying what each element is, and making that clarity part of how the content is expressed. The format gives that work somewhere useful to go.
This is why the advantage of HTML grows with scale. An organisation that builds authoring discipline into its publishing workflow produces content that reads well, is found readily, and stays useful over time. The value is visible in the content itself, in the readers it reaches, and in the systems that surface it.
Authoring discipline is one of the highest-leverage investments a publishing team can make. The gains apply to the content already produced, the content being produced now, and the content the team has not yet written. A small shift in how the team approaches authoring produces a cumulative improvement across the estate.
Moving existing content to HTML
For organisations with substantial PDF estates, moving existing content to HTML is more than a change of format. It is an opportunity to review structure, refresh navigation, verify reading order, clarify what each element of a document is, and make the content ready for the way it will be read on the web.
Adobe's own guidance on accessibility features of PDFs describes the work involved in adding structure to document files: tagging, reading order, descriptive text for images, table relationships, form fields, titles, and metadata. The same work, applied as part of intelligent conversion to HTML, produces a result in the format where that work delivers most benefit.
Intelligent conversion is therefore a quality-improvement process. Content that was previously held as fixed-layout files becomes structured web content. The organisation ends the exercise with a publishing estate that is easier to maintain, easier to surface to search and AI systems, easier for readers to use, and ready for the next cycle of updates.
For public-sector organisations in particular, this pathway supports the accessibility obligations that apply to public information, supports the public's right to reach the content in a usable form, and supports the organisation's own ability to maintain the content at scale.
What good HTML publishing looks like
Good HTML publishing is the product of a clear, consistent process. Content is authored with structure as part of the writing, not added afterwards. Each element carries its role in the content: headings express the outline of the document, lists describe related items, tables express the relationships between data.
Links describe where they lead, and images carry descriptive text alongside the visible content. Each habit is small in isolation, and compounding across a publishing estate the benefit is significant.
Testing is part of the workflow. Pages are reviewed with assistive technology, checked against the web accessibility baseline, and validated on the devices readers will use to reach them. Performance data is watched, and content is refreshed when the evidence suggests it is time.
At scale, this becomes an operational publishing model rather than a series of individual projects. Editorial, digital, accessibility, and communications teams produce content that reaches the audiences it was written for, and continues to reach them as the estate grows.
What this means for publishing policy
For senior leaders in digital, policy, publishing, accessibility, and communications, the practical conclusions follow directly from the evidence. HTML should be the default format for public-facing informational content. PDF should be retained only where a fixed, downloadable artefact is genuinely required, such as a form intended for print or a document kept as a point-in-time record.
Conversion of existing PDF content to HTML should be treated as a content-improvement workflow, with quality controls applied to structure, navigation, and readability. The authoring disciplines that produce good HTML should sit inside the publishing workflow, so the format carries the value it was designed to carry.
For local and municipal government decision-makers, the case is operational as well as editorial. Public-sector websites carry the reference content that citizens rely on to interact with services. That content needs to be findable, readable, and current across the devices citizens use. HTML is the format that supports all three as a native outcome of how the content is produced.
The case in one line
The public value of information depends on the public being able to reach it. For guidance, policy, and reference content, that reach is widest when the content is published in the format the web, its users, and the systems that serve them are designed around.
HTML is that format. The case is supported by public-sector publishing policy in the UK and US, by the web accessibility standards that govern inclusive publishing, and by research into how modern search and AI retrieval systems read public content. It is consistent across the authorities that govern each of those areas, and it points in the same direction in each case.
The practical value is cumulative. Content is more findable, readable on the devices and in the languages the audience uses, and accessible to readers using assistive technology. It is maintainable at scale, governable as a public record, and ready for the AI-driven retrieval systems that increasingly sit between the reader and the content.
Each of these values rests on the same foundation, which is that HTML carries meaning in the document itself. The format and the value are not separable, and that is why the case for HTML is a single case rather than a list of advantages.
Senior leaders responsible for the reach, quality, and effectiveness of public information have a practical decision in front of them. Publishing for people and the systems that serve them starts with HTML.
The tables below summarise these findings in operational terms.
Table 1. Accessibility and structural comparison by format
| Criterion | Native HTML | Well-authored tagged PDF | Typical real-world PDF | Intelligently converted HTML |
|---|---|---|---|---|
| Accessibility baseline | Strong | Conditional | Weak | Strong |
| Semantic structure | Strong | Conditional | Weak | Strong if mapping is correct |
| Reading order | Strong | Conditional | Weak | Strong if quality assured |
| Headings and navigation | Strong | Conditional | Weak | Strong |
| OCR and extractable text | Native text, strong | Conditional if born-digital or OCR'd | Often weak | Strong after verified OCR |
| Image alt text | Strong | Conditional | Weak | Strong if authored |
| Table interpretation | Strong | Conditional | Weak | Conditional to strong |
| Mobile responsiveness | Strong | Weak to conditional | Weak | Strong |
Table 2. Operational and machine-use comparison by format
| Criterion | Native HTML | Well-authored tagged PDF | Typical real-world PDF | Intelligently converted HTML |
|---|---|---|---|---|
| Maintenance and updating | Strong | Weak to conditional | Weak | Strong |
| Indexing and crawlability | Strong | Conditional | Conditional | Strong |
| AI retrieval and citation suitability | Strong | Conditional | Weak to conditional | Strong if structure is preserved |
| Analytics and interaction data | Strong | Weak | Weak | Strong |
| Linking and reuse | Strong | Weak to conditional | Weak | Strong |
| Governance and version control | Strong | Weak to conditional | Weak | Strong |
| Fixed-layout fidelity | Conditional | Strong | Strong | Conditional |
| Archival suitability | Conditional | Strong with PDF/A | Conditional | Conditional |
| Best default for public guidance | Yes | No, except in limited cases | No | Yes |
Table 3. Common PDF authoring failings and why they matter
| Common failure | Why it matters | Likely consequence |
|---|---|---|
| No meaningful heading hierarchy | Users and systems lose section boundaries | Poor navigation and weak topical segmentation |
| Incorrect reading order | Layout order diverges from reading order | Confused screen-reader output and brittle extraction |
| Image-based text or failed OCR | Text is not available as text | Poor searchability, poor accessibility, noisy summarisation |
| Weak or missing tags | Semantic roles are absent or unreliable | Heavier dependence on layout heuristics |
| Poorly structured tables | Header relationships are unclear | Data becomes hard to interpret or quote accurately |
| Missing alt text | Non-visual users and systems lose image meaning | Reduced accessibility and weaker context for retrieval |
| Weak titles, metadata, or link text | Document purpose is under-specified | Poor orientation, weaker trust, weaker machine interpretation |
Table 4. Recommended quality-assurance metrics for HTML-first publishing and conversion
| Metric | What to test | Why it matters |
|---|---|---|
| Searchable text coverage | Percentage of pages with a valid text layer | Distinguishes live text from image-only scans |
| Heading integrity | Logical H1-H6 structure and descriptive headings | Supports navigation, comprehension, and chunking |
| Reading-order pass rate | Manual review of complex layouts | Tests whether sequence survives conversion and remediation |
| Alt-text quality | Presence plus usefulness of text alternatives | Automated presence checks are not enough |
| Table semantics | Header associations and assistive-technology usability | Critical for accurate human and machine interpretation |
| Link purpose | Whether link text makes sense in context | Improves accessibility and destination clarity |
| Title and metadata quality | Document titles and page metadata | Improves orientation and machine understanding |
| Mobile reflow | Behaviour at narrow viewports and high zoom | Tests practical readability rather than nominal availability |
| Human-and-system retrieval test | Can people and systems locate the right passage accurately | Connects publishing quality to real use |
Table 5. Publishing decision framework
| Scenario | Primary publication | Secondary output | Practical note |
|---|---|---|---|
| Public guidance mainly intended for online reading | HTML | Optional PDF | Default case |
| Frequently updated reference content | HTML | Optional PDF | Reduces version drift and maintenance overhead |
| Scanned or structurally weak legacy PDFs | Converted or re-authored HTML | PDF retained where needed | Treat as content remediation |
| Signed, fixed-fidelity, or archival artefacts | PDF or PDF/A where required | HTML equivalent where possible | Exception model |
| Users need printable or offline copies | HTML | PDF companion | Download should not replace canonical web content |
Sources
The sources below were consulted in the preparation of this article and directly support the claims made in the body. Each is linked on first mention in the text above.
- GOV.UK. Publishing accessible documents. https://www.gov.uk/guidance/publishing-accessible-documents
- GOV.UK. Content design: content types. https://www.gov.uk/guidance/content-design/content-types
- Government Digital Service (July 2018). Why GOV.UK content should be published in HTML and not PDF. https://gds.blog.gov.uk/2018/07/16/why-gov-uk-content-should-be-published-in-html-and-not-pdf/
- W3C. Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/
- W3C Web Accessibility Initiative. Page Structure Tutorial. https://www.w3.org/WAI/tutorials/page-structure/
- W3C Web Accessibility Initiative. Understanding Reflow (WCAG 2.1). https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
- Section508.gov. Create Accessible PDFs. https://www.section508.gov/create/pdfs/
- Google Search Central. File types indexable by Google. https://developers.google.com/search/docs/crawling-indexing/indexable-file-types
- Google Search Central. Introduction to structured data markup in Google Search. https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
- Google Search Central. AI features and your website. https://developers.google.com/search/docs/appearance/ai-features
- Microsoft Learn. Generative AI on public websites (Copilot Studio guidance). https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/generative-ai-public-websites
- Wang et al. (2024). READoc: A Unified Benchmark for Realistic Document Structured Extraction. https://arxiv.org/html/2409.05137v3
- Ouyang et al. (2024). OmniDocBench: Benchmarking Diverse PDF Document Parsing with Comprehensive Annotations. https://arxiv.org/html/2412.07626v2
- Adobe. Accessibility features of PDFs (Adobe Acrobat guidance). https://helpx.adobe.com/uk/acrobat/using/accessibility-features-pdfs.html