PDF to HTML: Why the Output Is a Pile of Divs

You ran a 20-page report through a PDF-to-HTML converter expecting a web page. What came back opens in a browser and looks almost right, and the source is four thousand absolutely-positioned <div> elements with a stylesheet that pins every line of text to a coordinate.

Nothing malfunctioned. That output is the correct answer to a question you did not realise you were asking.

The Two Formats Do Not Share a Concept

A PDF page is a coordinate system. The content stream is a list of drawing operators: begin a text object, select a font, move the text matrix to an (x, y) position, show these glyphs, end the text object. That is the whole model.

There are no paragraphs in a PDF. No headings, no lists, no reading order, no table cells. What you perceive as a paragraph is a run of glyph-drawing commands that happen to sit near each other. In many PDFs there is not even a concept of a word — the space between two words is a coordinate offset between glyphs, not a character. A single visual line of text is often split across several drawing operators with manual kerning nudges between them.

HTML is the opposite kind of thing. Content flows, reflows to the viewport, and carries structure in its markup: <h2>, <p>, <ul>, <table>.

So a converter cannot translate. It has to infer — reassemble glyphs into words from inter-glyph spacing, words into lines from vertical proximity, lines into paragraphs from indentation and leading, then guess at headings from relative font size, at columns from whitespace gaps, at tables from the alignment of text and the position of drawn rules. Every one of those is a heuristic, and heuristics are wrong sometimes.

As IDRsolutions puts it: "A straight conversion is not possible. PDF files can contain a large number of structures which have no direct equivalent in HTML."

Two Honest Approaches, and You Have to Pick One

Every converter resolves the mismatch in one of two directions. This is the fork that explains the div soup.

pdf2htmlEX — the best-known free option, built on Poppler, Cairo and FontForge — chose the left column deliberately. It extracts the embedded fonts, converts them to WOFF, and pins every text run to its original position. That is why the output looks so faithful and why it is so unpleasant to work with afterwards. It is not a misconfigured semantic converter. It is a fidelity tool doing its job. (The original project is unmaintained; the active community fork is where the bug fixes live.)

Poppler's simpler pdftohtml sits closer to the middle and degrades harder on complex layouts. PyMuPDF's get_text('html') throws away block structure and merges paragraphs into flat lines. Commercial SDKs like BuildVu, Aspose and PDFix will produce genuinely semantic HTML5 with headings, landmarks and ARIA attributes — which is the right answer, and is also a licence negotiation rather than a command.

Pick the column that matches the job. If you need an archival facsimile, take absolute positioning and stop fighting it. If you need a web page, take reflow and accept that it will not be a pixel match.

What Reliably Breaks

Budget for cleanup on all of these, because no converter handles them all:

Tables without visible borders. A PDF has no table structure — a table is text and lines drawn at coordinates. When there are no rules to detect, the converter is inferring a grid from alignment alone. Merged cells get misidentified. Nested tables flatten to text.

Multi-column reading order. Two columns of text, a sidebar beside body copy, and an actual two-column table look identical at the coordinate level. Get it wrong and the output interleaves paragraphs from both columns.

Fonts. PDFs embed subsets containing only the glyphs used, which makes them incomplete as web fonts. Font licensing may forbid web embedding outright. Type 3 bitmap fonts are unsupported almost everywhere. Substituted fonts have different metrics, so text overflows the containers that were sized for the original.

Headers, footers and page numbers. They repeat on all 40 pages in the PDF and should appear once or never in HTML. Converters that do not deduplicate produce output littered with page furniture mid-document.

Then the things that have no HTML counterpart at all. Formulas get drawn as individually positioned glyphs or flattened into images, and reassembling them into MathML takes detection that general-purpose converters do not have. PDF carries CMYK, spot colours and ICC profiles where CSS has RGB and HSL, so colour shifts are routine rather than a bug. AcroForm validation has no equivalent, and signature fields cannot convert in any form — they are cryptographic assertions about a specific byte sequence, and the bytes are about to change.

The Output That Looks Right and Is Not

This is the failure worth naming separately, because it passes a visual check.

Converted output can render correctly in your browser while being unsearchable (text rendered as images), unstructured (no heading hierarchy for a screen reader to navigate), non-responsive (correct only at the original page width), and uneditable (every text change fights the coordinate CSS).

If you are converting because you want the content on the web, "it looks the same" is the wrong acceptance test. Open the result and check three things: does the source contain real heading elements, does the text survive being read as plain text, and does the layout hold at 400px wide.

The Accessibility Case, Which Is Usually the Real Driver

Most people converting PDFs to HTML at scale in 2026 are doing it for compliance, not aesthetics.

The DOJ's interim final rule moved the ADA Title II compliance deadline to 26 April 2027. The FY 2025 federal assessment found that public-facing PDFs have the lowest Section 508 conformance of any document type — worse than web pages, worse than internal documents. Fixing a PDF's accessibility means tagging structure, reading order and alt text inside a format that resists all three. Converting to HTML means working in a format built for it.

The scale of that work is why AI-assisted conversion is showing up in government. North Carolina's IT department used Google's Gemini to convert government PDFs to HTML. Torchbox and FRC moved over 7,800 documents. LocalGov Drupal's AI-powered PDF importer won a Digital Leaders AI Impact Award. None of that would exist if hand-remediating PDFs were tractable.

If accessibility is your driver, the semantic column is not a preference. Absolutely-positioned divs fail the thing you are converting for.

Where Your File Goes While You Do This

Nearly every online PDF-to-HTML converter is server-based, and the free tiers are meters: Zamzar allows two conversions a day at 25 MB, Smallpdf two tasks a day at 5 MB, CloudConvert 25 a day, Convertio ten.

The retention picture matters more. A 2026 survey of twelve online converters found eight retained uploaded files for at least 24 hours, and four had terms of service permitting content access for "service improvement" — language broad enough to cover a lot. If the report you are converting is a published annual review, none of this is a problem. If it is an internal document, a client deliverable, or anything with names in it, you have handed a copy to a third party to get an HTML file back. That is a trade worth making deliberately rather than by default.

What to Actually Do About It

Being straight with you: there is no PDF-to-HTML tool on this site. Sixty-plus tools and that is not one of them.

What works instead is a two-step that lands you in the semantic column on purpose, and it is a better path than most direct converters take.

Convert the PDF to Markdown in your browser. Markdown has no coordinates — it only has structure, so the conversion is forced to commit to headings, paragraphs and lists rather than pinning text to positions. Then run the Markdown through any renderer and you get clean semantic HTML: real <h2> elements, real <p>, real <ul>, nothing absolutely positioned. You will fix some heading levels and rebuild the difficult tables by hand. You were going to do that anyway — the difference is you are editing structure instead of untangling CSS.

For content-only jobs where layout is irrelevant, extract the text and mark it up yourself. If the PDF is a scan with no text layer at all, run OCR first or you are converting pictures of words. And if you need the figures out of the document as real assets, pull the pages as SVG rather than letting a converter re-encode them.

All of it runs locally, which means no upload, no daily cap, and no retention window to read.

Worth knowing the reverse direction is much easier, and for the same reason: going from HTML to PDF means throwing structure away to fix a layout, and discarding information is always simpler than inferring it. Converting PDF to HTML is asking a converter to guess what the author knew and the format did not record.