There are two things people mean by PDF to HTML. One is a document: headings, paragraphs, lists and tables, which reflows, reads on a phone and can be edited. The other is a picture of the page made of HTML, every line in a positioned box, which looks identical and is good for nothing else.
This builds the first. The converted document is shown rendered before you download it, because a heading that came out as a paragraph is obvious on sight.
Ask for a PDF as HTML and you will be handed one of two very different things, usually without being told which. It is worth knowing the difference before you pick a tool, because the wrong one wastes an afternoon.
The two conversions, and which one you want
Real h1 to h4, p, ul, ol and table elements.
Reflows to any width, reads on a phone, works with a screen reader.
Editable: change a heading, restyle it, paste it into a template.
Small. A twenty page report is a few tens of kilobytes.
The page layout is gone. Columns become one column.
Every line in an absolutely positioned div, at the coordinate it had.
Looks identical to the PDF, at one width, on a large screen.
Reflows nowhere. On a phone you pan around it.
Large, and carries embedded fonts to match the original.
Close to uneditable: moving one word moves nothing else.
The second is what tools like pdf2htmlEX produce, and for archiving a page exactly as it was printed it is the right answer. For almost everything else, including anything that has to be read, searched, indexed or edited, it is not. This tool builds the first kind and says so rather than implying it does both.
A PDF does not contain paragraphs
This is the part that surprises people, and it explains everything else on this page. A PDF does not store a document. It stores instructions for drawing one: put this glyph here, in this font, at this size. There is no paragraph, no heading, no list and no table anywhere in the file.
- Glyphs into lines, by baselinegeometry
- The body size, from the whole documentstatistics
- Lines into paragraphs and tablesspacing
- Each block into an elementmarkup
Some PDFs carry structure tags describing exactly this, and a tagged PDF converts beautifully. Almost none of the PDFs people actually have are tagged, so a converter that relies on them fails on the documents that matter.
How a heading is recognised
A heading is a line that is bigger than the text around it. That sounds too simple to work and it is, until you make the comparison relative rather than absolute.
Weight is the other signal, and it is harder than it looks, because a PDF names its fonts rather than describing them. There is no bold flag to read: there is a name like HelveticaNeue-CondensedBlack or NimbusRomNo9L-Medi, and working out that both mean bold takes a list of conventions rather than a rule.
A table is lines that agree about where the columns are
Tables are the hardest part, because a PDF table is usually not drawn as a table at all. It is text at coordinates, sometimes with lines around it and often without.
The test has to be strict, because getting it wrong in the other direction is worse: a page of prose turned into a table is unreadable, while a table left as text is merely disappointing. Two columns of a label and a figure on every row, for instance, are read as a list of figures rather than a table, because that is what they usually are.
h1 to h4, p, ul, ol, table, th, td.
Doctype, title, viewport and styles inline.
Before anything is downloaded.
The line that appears on every page
Running headers and footers are the other thing a PDF has and a document does not want. Converted naively, a forty page report comes out with the company name and a page number wedged between every section.
A line that appears near the top or the bottom of most pages is furniture. Page numbers are normalised out before the comparison, so "Page 4 of 12" and "Page 5 of 12" are recognised as the same line, and three pages is the minimum evidence: two could be a coincidence. The result says how many were dropped, and the option can be turned off when the repeated line is part of the content.
What the HTML is good for
Putting a document on the web
Search engines index HTML text properly and treat a PDF as a second-class citizen. A report as a page outranks the same report as a download.
Making it readable on a phone
A PDF on a phone is a zoom-and-pan exercise. The same content as HTML reflows to the screen.
Getting the content into a CMS
Turn the stylesheet off and the markup pastes straight into a template with nothing to strip out first.
Accessibility
A screen reader can follow real headings and real table cells. An untagged PDF gives it a stream of glyphs.
If what you want is text without any markup at all, Markdown is the same conversion with a lighter syntax, and it uses exactly this engine. If you want the document back as a word processor file rather than a web page, PDF to Word is a different engine built for that.
Why this runs in your browser
Converting a PDF means reading every word of it. That is a poor reason to send a contract, a medical letter or an unpublished manuscript to a server, and it is unnecessary, because the reading engine is the same one your browser already uses to display PDFs.
The file is opened in memory, the layout is worked out, the HTML is built and handed to you as a download. Nothing is transmitted, nothing is stored, and closing the tab is all the cleanup there is.
The tool is right above
Drop a PDF, look at how it read the document, and take the HTML.
Common questions
What it produces, what it infers, and what it leaves out.
01Will the HTML look like the PDF?
Not exactly, and that is the choice this makes rather than a shortcoming. It produces a document with real headings, paragraphs, lists and tables, styled to be readable at any width. A pixel copy of the page is a different job, done by putting every line in an absolutely positioned box, and the result reflows nowhere, reads badly on a phone and is close to uneditable.
02Are images included?
No. The text and its structure come through; pictures do not. If you need the images as well, run the file through the image extractor, which pulls them out at their original resolution, and add the ones you want.
03Is the HTML a whole file or a fragment?
Whichever you pick. By default it is a complete document with a doctype, a title, a viewport tag and a short stylesheet inline, so it opens in a browser and stands on its own. Turn the stylesheet off and you get clean unstyled markup to drop into a page or a template.
04Why did a line come out as a heading when it is not one?
Because it is larger or bolder than the body text around it, which is the only evidence a PDF offers. A pull quote, a figure caption in a heavier face and the first line of a letterhead all look like headings from the inside. The preview is there for exactly this, and fixing one line in the source is faster than any setting could be.
05Does it work on a scanned PDF?
No. A scan is a picture of a page with no text in it to read, so there is nothing to convert and the tool says so rather than handing you an empty file. Run it through OCR first and then come back.
06What happens to the header and footer on every page?
A line that appears near the top or the bottom of most pages is treated as furniture and dropped, with page numbers normalised out first so that page 4 of 12 and page 5 of 12 count as the same line. The count of what was dropped is in the result, and the option can be turned off.
07Is the text still selectable and searchable?
It is text in an HTML file, so yes, entirely. It can be searched, copied, restyled with your own CSS, read aloud by a screen reader and indexed by a search engine, none of which is true of a PDF embedded in a page.
08Are my files uploaded anywhere?
No. The PDF is read and converted in your browser and the HTML is built there. Nothing is transmitted and nothing is stored.