Publish PDF content as HTML people can read on a phone

A PDF on a website is a dead end for a lot of readers. It downloads instead of opening, it is unreadable on a phone without pinching, screen readers handle it inconsistently, and search engines treat it as a second-class citizen. Converting the content to HTML fixes all of that — provided you pick the right kind of HTML.

When a web page beats linking the PDF

Before converting anything, the test is who the document is for and what they need to do with it.

Convert to a web page when the content is meant to be read by a general audience: guidance, policies, articles, reports people will land on from search. A web page opens instantly, reflows to a phone, respects a reader's font size, works with screen readers, and can be indexed properly. A linked PDF loses on every one of those.

Keep the PDF when the document is meant to be filed, printed, or relied on as a record: forms, signed agreements, statements, anything where pagination or exact appearance carries meaning. There the fixed layout is the feature.

The two are not exclusive. The common pattern is to publish the readable web page as the primary destination and offer the PDF alongside it for anyone who needs the formal artefact. That way the content is findable, and the record is still available to the people who actually need it.

How to convert a PDF into a web page

The mechanics are short; the judgement is in step three.

1. Open the convert a PDF into a web page tool and select your file. The document is read in the browser, so nothing is uploaded to a conversion service.
2. Confirm the PDF has real text. Select a sentence in any reader — if nothing highlights, the pages are images and no converter can recover structure from them. Run recognition first, as described in check whether a PDF needs OCR.
3. Choose the output mode. Semantic reflow for anything people will read; positioned for a visual facsimile. The next section explains why this is the decision that matters.
4. Convert, then read the result at a narrow window width before anything else. Most conversion faults are visible immediately at phone width.
5. Download either a single self-contained file or a package with the images alongside, depending on where the output is going.
6. Fix reading order and headings by hand. Expect this; it is normal work, not a sign the conversion failed.

A converter produces a draft, not a finished page. The value is in skipping the retyping, not in skipping the editing.

Two very different outputs

The tool offers two modes that produce almost opposite results.

Positioned visual HTML. Every text run is wrapped in an element with absolute coordinates, reproducing the page exactly. Fonts, columns, and spacing all match. It looks perfect on a desktop at full width and it is effectively unusable on a phone, because absolute positioning cannot reflow. It is also poor for accessibility, since the markup describes positions rather than meaning.

Semantic reflow. The content is rebuilt as ordinary HTML: headings, paragraphs, lists, and tables, in reading order, with no absolute positioning. Text wraps to any width, the browser's font size settings work, screen readers follow the structure, and search engines can parse it. It will not look identical to the PDF, which is the entire point.

Goal	Mode
Publishing content on a website	Semantic reflow
Reading on a phone	Semantic reflow
Accessibility compliance	Semantic reflow
An exact on-screen facsimile of the page	Positioned
Archiving a visual record	Positioned
Extracting content to edit and republish	Semantic reflow

For most real purposes, semantic reflow is the right choice. Positioned output answers a narrow question: what did this page look like?

Reading order is the thing to check

A PDF stores glyphs at coordinates and draws them in whatever order the producer chose. That order has no obligation to match how a human reads the page, which is the root cause of most conversion oddities.

So after converting, check specifically for:

• Multi-column pages interleaving, giving a line from column one followed by a line from column two.
• Headers and footers appearing mid-content, repeating once per original page.
• Sidebars and pull quotes interrupting a sentence.
• Footnotes detached from their references.
• Captions separated from their figures.

These are correctable by hand, and knowing they are structural rather than random makes the correction quick. The text extraction guide explains the underlying mechanism in more detail.

Details worth fixing after conversion

If the output is going on a public website, a few things repay the effort:

1. Heading hierarchy. Confirm headings became real heading elements at the right level, and in order. This drives both navigation and accessibility.
2. Alternative text for images. Nothing in a PDF supplies it unless the original was tagged, so it has to be written.
3. Table headers. Mark header cells properly so screen readers can associate data with columns.
4. Link text. Bare URLs converted from a printed document should become descriptive links.
5. Hyphenation artefacts. Words broken across original line ends can survive as manage-ment.
6. Ligatures. The single glyph fi may not match a search for "fi".

Images and fonts

Embedded images are extracted and referenced from the HTML. Two things to watch: image resolution may be much higher than a web page needs, so recompress before publishing; and font references may point at fonts that were embedded in the PDF but are not available to a browser, so specify web-safe fallbacks in your CSS rather than accepting substitution.

Related routes

• For reading rather than publishing, the EPUB export tool produces a reflowable book format that reading apps handle better than a web page.
• For just the words, extraction is faster than any conversion.
• For the opposite direction, rendering HTML into a paginated PDF is covered in the HTML to PDF guide, and it is by far the easier trip, because you are discarding adaptability rather than trying to recover it.

That asymmetry is worth remembering when planning a publishing pipeline. If content will exist in both forms, author it as HTML or Markdown and generate the PDF from that source. Converting the other way is always recovery work.