PDF to HTML — self-contained single-file output and the trade-offs of heuristic conversion
Converting a PDF to HTML is one of those operations where the right shape of output depends entirely on what comes next. Some users want a styled wiki page; others want a self-contained file they can drop into any CMS without external dependencies; others want skeleton HTML to manually polish in a code editor. Our free heuristic converter produces option two — a single .html file with inline CSS, browser-ready, no CDN dependencies, no external stylesheets. Here is what the converter does, what it preserves, what it loses, and the three downstream pipelines where this exact shape of output earns its place.
How the heuristic converter works
The tool parses the PDF with pdfjs to extract every text run along with its font size and weight. We build a font-size histogram across the document — the mode is body text; sizes ≥1.25× body become H3, ≥1.6× become H2, ≥2× become H1. Bold runs become <strong>; italic runs become <em>. Paragraphs are separated by line-spacing analysis. Pages are separated by <hr> elements.
The output is wrapped in a single .html file with inline CSS rather than a separate stylesheet. Helvetica is the default font; H1/H2/H3 styles use distinct sizes; paragraphs get standard spacing. No JavaScript, no external assets, no CDN references. Drop the file into any browser and it just works.
What survives the conversion
Heuristic extraction preserves the content elements most users actually want:
- Text and reading order. Every word in reading order, multi-column pages linearized correctly for most layouts.
- Heading structure. H1/H2/H3 detected from font-size hierarchy. Well-typeset documents get publication-ready heading levels.
- Bold and italic. <strong> and <em> tags wrap runs that were styled. Mixed-style runs combine correctly.
- Paragraph structure. Line-spacing analysis groups runs into paragraphs separated by visual gap.
- Page separation. <hr> elements mark page boundaries, so the visual flow of the source PDF is preserved in the HTML.
What the heuristic doesn't handle
Three categories of content where the free heuristic falls short, with the right tool for each:
- Tables. Tables are layout-dependent and the heuristic linearizes them row-by-row, losing column structure. For tabular content use AI · Table Extract to pull tables as CSV, then embed them in HTML separately.
- Images. Embedded images are not extracted into the HTML. Visually, the HTML output lacks any picture content from the source. For documents where images matter, run Extract Images separately, host them, and reference them in the HTML manually. Or use AI · Rewrite which handles image positioning end-to-end.
- Hyperlinks. The free converter doesn't carry forward PDF hyperlinks into HTML <a> tags. URLs that appear as visible text in the PDF still appear as text in the HTML — they're just not clickable. Manual post-processing can wrap them; or use AI conversion for hyperlink-aware output.
Three downstream pipelines where this output shape works
Specific workflows where heuristic HTML conversion is the right intermediate:
- Wiki / CMS migration. Pasting documentation into Confluence, Notion, or a custom CMS. The converted HTML is clean enough to paste; the CMS's import handles the styling. Saves manual retyping or copy-paste-then-restyle.
- Web publishing. Publishing an old PDF as a web page. Since the HTML is self-contained, you can drop it directly into a static site generator, GitHub Pages, or any web host without dependency setup. Search engines crawl HTML far better than PDFs — turning the PDF into HTML improves discoverability.
- Text-only LLM ingestion. Some LLM ingestion pipelines prefer HTML over plain text because the tag structure preserves heading hierarchy. The converter is a single-step PDF → ingestible HTML path.
When to skip this tool
Three cases where a different format is right:
- You want pure text without tags. Use PDF-to-Text. Strips all formatting; pure UTF-8 .txt output. Faster for cases where structure doesn't matter.
- You want markdown for a developer workflow. Use PDF-to-Markdown. Markdown is more developer-native for README files, wiki pages, and AI training data than HTML.
- You need pixel-perfect visual fidelity. Heuristic conversion doesn't preserve exact PDF layout. For visual fidelity, rasterize the page (PDF-to-PNG) and embed the image — content is no longer text-extractable but visual fidelity is perfect.
Limits and compatibility
On the free web tool, PDF-to-HTML handles PDFs up to 100 MB. Parsing runs in your browser via pdfjs; nothing is uploaded. Output is a single self-contained .html with inline CSS. Opens in every browser, every WYSIWYG editor, every wiki / CMS import.
Common pairings: PDF Inspector first to verify the source has a text layer (scans return empty HTML). PDF-to-HTML → manual edit pass when downstream destination needs fine-tuned markup. AI · Rewrite when the heuristic output isn't quite enough.