Converting a PDF to HTML is not a format translation — it's a reconstruction. HTML describes structure ("this is a heading, this is a table") while a PDF mostly describes position ("draw these glyphs at these coordinates"). Everything a good converter does amounts to inferring the structure that the PDF never explicitly recorded.
Why PDFs have no structure
A PDF page is a set of drawing instructions. What looks like a heading is text drawn larger and higher up; what looks like a table is text positioned in a grid, sometimes with lines drawn around it and sometimes not. Nothing in the file says "heading" or "table cell" unless the PDF is tagged — carrying an accessibility structure tree, which files exported from well-configured tools do and files produced by scanners and older exporters do not.
So conversion quality depends first on what's in the file. Tagged PDF: the structure is there to read. Untagged PDF: the converter infers structure from font sizes, spacing and alignment. Scanned PDF: there's no text at all, only an image of text — run OCR first or you'll convert a picture into an HTML page containing one picture.
Two kinds of output
Fixed-layout HTML reproduces the page exactly using absolute positioning. It looks identical to the PDF and is right for archival viewing or an in-browser viewer. It does not reflow on a phone, and its markup is positioned <div>s — poor for search engines, screen readers and copy-paste.
Responsive semantic HTML rebuilds the content as <h1>, <p>, <ul>, <table> and <img>. It reflows, it's accessible, it's indexable, and it's editable. The trade is visual fidelity: exact page geometry is gone, and that's the point.
Pick by intent. Publishing a report to the web, feeding a CMS, making content accessible or searchable → responsive. Reproducing a document faithfully in a browser → fixed.
curl -X POST https://www.ashdocs.com/api/v1/tools/pdf-to-html \
-H "X-API-Key: ash_live_..." \
-F "files=@annual-report.pdf" \
-F 'options={"mode":"responsive","inline_images":true}'
The PDF to HTML API returns the HTML plus its assets, so you can drop the result into a CMS or a template.
What usually survives
Headings, when the PDF is tagged or when heading sizes are visually consistent. Paragraphs. Ordered and unordered lists. Links, including internal jumps. Images, either extracted as files or inlined. Simple ruled tables.
What usually breaks
Multi-column reading order. Academic papers, newsletters and brochures read left-to-right across both columns unless the converter is layout-aware, producing alternating sentence fragments. Test a two-column document early — it's the fastest way to judge a converter.
Complex tables. Merged cells, nested headers and borderless tables are where table reconstruction fails. If the data matters more than the appearance, extract it properly with a table extraction endpoint and render it yourself.
Repeating headers and footers. They were page furniture; in a reflowed document they become text interrupting the content every few paragraphs. Good converters strip repeated elements.
Fonts. Embedded fonts are subset — only the glyphs used are included — so they can't simply be reused on the web. Expect substitution, and map to web fonts deliberately rather than accepting whatever the converter guesses.
Ligatures and encoding. Some PDFs encode "fi" and "fl" as single glyphs, so searching the output for "workflow" misses "workflow". Normalise Unicode after conversion.
Footnotes. Positioned at the page bottom but belonging to a sentence elsewhere. They tend to land mid-paragraph in reflowed output; move them to the end of the section or drop them.
Where it's actually used
Publishing existing PDF reports as indexable web pages — the most common commercial reason, because a PDF ranks poorly and reads badly on a phone. Building an in-browser viewer without shipping a plugin. Making documents accessible, since semantic HTML works with screen readers in ways an untagged PDF cannot. Migrating legacy documentation into a CMS. And preparing content for machines — although if the destination is a language model rather than a browser, Markdown is the better target: same structure, far fewer tokens.
FAQ
Can I convert a scanned PDF to HTML? Not directly — a scan contains images, not text. Run OCR first to create a text layer, then convert.
Will the HTML look exactly like the PDF? Only in fixed-layout mode, which reproduces page geometry with absolute positioning. Responsive mode trades exact appearance for content that reflows and is accessible.
Why is the text out of order? Almost always a multi-column layout read straight across the page. Layout-aware conversion follows the columns; naive extraction doesn't.
PDF to HTML or PDF to Markdown? HTML for the web and browsers. Markdown for LLM and RAG pipelines, where structure matters and token count does too.
Do tables convert reliably? Simple ruled tables usually do. Merged cells and borderless tables often don't — extract those as structured data instead of trusting the reconstruction.
Convert your first PDF free — 100 credits, no card required.