The mobile problem is not a side issue. It is now central to how public information is consumed. Guidance, policy, forms, reference documents and service information are routinely opened on phones during travel, between meetings, from email links, from search results and in moments where the user wants a quick answer rather than a file to manage, in that setting format matters.
PDFs were never designed for that kind of use, they were built to preserve page layout, not to adapt cleanly to changing screen sizes, browser settings and reading contexts. That is why public-sector guidance has moved in a clear direction. Government guidance in the UK says HTML should be the first choice wherever possible, while US federal accessibility guidance says agencies should prioritise HTML and use PDFs only when necessary.
The point is not that every PDF fails some are well made, some remain necessary.
The stronger and more useful point is that PDF is often the wrong default for mobile readers. It creates friction where HTML removes it. It preserves layout where mobile users need flexibility. It pushes the reader into zooming, scrolling and app-switching where a responsive page would simply open and work.
Government Digital Service, Why GOV.UK content should be published in HTML and not PDF; Government Digital Service and Central Digital and Data Office, Publishing accessible documents; Section508.gov: Create Accessible PDFs.
PDF keeps the page. Mobile users need the content.
The basic conflict is straightforward. A PDF tries to hold its layout steady. A mobile reader needs content that can adjust. On a responsive web page, text reflows, margins shift, navigation stays available and the browser remains in control. On a PDF, the page itself becomes the fixed object. The user has to adapt to it.
Government Digital Service describes the result directly.
PDFs generally require a lot of zooming in and out, and scrolling both vertically and horizontally. It states that this is especially troublesome on long documents and on small devices such as mobile phones. That is not a minor design weakness. It changes the effort required to read the content at all.
HTML solves this in a more natural way because it allows the content to fit the device. The user is not forced to read a reduced image of a printed page. They are given text, structure and navigation that can move with the screen size.
Zooming is not neutral. It is a reading penalty.
A common mistake is to treat zooming as an adequate answer. In practice it is a tax on attention. The user pinches in, pans across, loses the line, adjusts again, and repeats the process for each paragraph, table or figure. Even when the text is technically visible, the reading experience is broken into mechanical tasks.
This matters because public information is often read under time pressure. People open a policy note on a phone because they need the answer now. They do not want to manage a page image. They want to read. A format that interrupts basic reading in order to preserve layout is serving the document rather than the user.
That is one reason GOV.UK says HTML is the most accessible format for publishing documents and should be the first choice whenever possible. It is also why Section508.gov says PDFs are often not the most accessible or mobile-friendly option.
The issue is not merely compliance language, it is everyday usability.
Mobile reading depends on context, not just text size.
A good mobile reading experience is not only about whether words are legible. It also depends on orientation, navigation and continuity. When a user opens a normal web page, they remain within the website. The surrounding navigation, related links, page title and browser tools remain available. They can move naturally through the information.
PDFs often break that flow and depending on the device and browser, they may open in a new tab, a separate viewer or another app, sometimes they download instead. Government Digital Service notes that when this happens, users are taken away from the website and lose the context of the site and its navigation.
That problem is greater when the user arrives directly at the PDF from search, because they have the file but not the surrounding structure that explains where they are or what to do next.
On mobile, where screens are smaller and app switching is more disruptive, this loss of context is more pronounced. What should have been a quick answer becomes a fragmented experience.
Mobile accessibility is weaker when content is locked into a PDF.
Mobile users do not all read in the same way, some increase text size, some change colour even rely on browser settings or assistive technology. Some use landscape orientation. Some need strong contrast or clearer layout. HTML supports far more of that flexibility because the browser and operating system can still do their work.
Government guidance on accessible documents points to the same issue. Publishing in HTML allows documents to use the user's custom browser settings. It warns that PDFs do not work well with assistive technologies a lot of the time. The GDS blog makes the point more sharply for everyday users: once content is locked into a PDF, people have less ability to make the accessibility customisations that help them read comfortably.
This is particularly relevant on mobile because small screens already create pressure. If the format also resists reflow, ignores user settings, or behaves badly with assistive tools, the reading burden increases fast.
Tables, diagrams and dense layouts usually get worse on phones, not better.
PDF-heavy publishing is often defended on the grounds that reports, tables and charts need a fixed layout. That may preserve the appearance of the page, but it does not preserve usability on a phone. Dense tables become miniature images and multi-column layouts become awkward and sequential reading becomes unclear. Diagrams are harder to interpret when the viewer is forced to zoom and pan just to inspect labels.
The problem here is not theoretical, GOV.UK's accessible document guidance advises keeping layouts clear, using single continuous columns where possible, and avoiding merged or split table cells because they are harder to make accessible. Those points matter even more on mobile devices, where complex layouts collapse into effort.
HTML does not remove complexity on its own, but it gives teams better tools to present structured information in a form that can adapt to smaller screens. That is a better foundation for mobile reading than a fixed page export.
PDF-first publishing creates mobile friction at scale.
The wider issue is operational, when an organisation defaults to PDF, mobile friction is repeated across every public document. Each policy paper, guidance note or service explainer carries the same weaknesses forward. The result is not one difficult file. It is a publishing model that repeatedly asks mobile users to work harder than they should.
This is why the case for HTML is stronger than the case against a single PDF. HTML scales better because it is built for screen reading, not print preservation. It keeps navigation intact, supports responsive behaviour, works better with browser controls and reduces the amount of effort required from the reader.
The format decision therefore has a cumulative effect. An HTML-first approach improves every future mobile reading journey. A PDF-first approach keeps recreating the same problems.
Where PDF still has a place
There are still cases where PDF remains useful. A downloadable record copy, a print-oriented version of a report, an archive file or a signed document may all justify a PDF. The mistake is to let those exceptions define the default.
Public content that is expected to be viewed online should usually be published in HTML first. If a PDF is still needed, it should usually sit behind that HTML version as a secondary download. That approach preserves the convenience of a file where it is genuinely useful without forcing every reader into a file-first experience.
Conclusion
The mobile case against PDF-first publishing is straightforward. PDFs hold the page steady when mobile readers need content to adapt. They make zooming and panning more common and they can break navigation context. They offer less flexibility for browser settings and assistive technologies. They are often the wrong object for a phone screen.
That is why government guidance keeps returning to the same position. HTML should usually be the default for public-facing information. PDF may still have a role, but it should not be the primary reading experience for content that people need to open, understand and use on mobile devices.
For organisations that want public information to be readable, usable and current wherever it is opened, the practical answer is clear: publish for the screen first, and treat the downloadable file as secondary.
Sources
All sources are listed below with direct links.
- Government Digital Service. 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/
- Government Digital Service and Central Digital and Data Office. Publishing accessible documents. https://www.gov.uk/guidance/publishing-accessible-documents
- Government Digital Service. How to publish on GOV.UK: Accessible formats. https://www.gov.uk/guidance/how-to-publish-on-gov-uk/accessible-formats
- Section508.gov. Create Accessible PDFs. https://www.section508.gov/create/pdfs/