Drop your PDF into the zone below and get back an editable web page. Headings become heading elements, bullet points become list items, and columns of figures become real table rows, rather than a wall of absolutely positioned text boxes that nobody can restyle. Choose a complete standalone document with its own stylesheet, or just the body markup to paste into a page you already have. Nothing is uploaded. The extraction runs on your own processor.
Your files are read by JavaScript running on your own machine. There is no upload, no queue, and no copy on our server to delete later.
Drag a card to reorder it, or use the arrows under each card. The order here is the order in the output. Each card is a preview of the finished page, so what you see is what the PDF will contain.
Esc close ← → move R rotate
Starting
This is your processor doing the work, so the time it takes depends on your machine and not on how many other people are on the site.
The converter above is ready to use. The guide below is the part that explains what is actually recoverable from a PDF - why a document stores coordinates rather than structure, how a heading is identified when nothing in the file says "heading", what makes a table detectable, and how to tell within ten seconds whether your particular PDF will convert well or not at all.
Two minutes, nothing to install, and no account needed for your first run. This PDF to HTML converter executes inside the page you are reading, so every step below happens on your machine and your document is never transmitted anywhere.
Click the drop zone above or drag the file anywhere onto this page. The document is parsed as it lands and the card shows its page count, so a file that is password protected or damaged reports it before you spend an operation on it.
Real HTML reads the text layer and rebuilds headings, paragraphs, lists and tables as elements you can edit and style. That is the mode you want. Pages as pictures embeds each page as an image instead, which reproduces a scanned document exactly and cannot afterwards be edited, searched or restyled by anybody, including you. If your PDF is a photograph of paper, that second option is the only one that will produce anything.
Complete web page writes a full document with a doctype and a small stylesheet that follows light and dark mode, ready to open in a browser. Switch it off for body markup only. That is what you want when the content is going into a page you already have. Add heading ids to make every section a link target, and a table of contents if the document runs long.
Press Convert to HTML and the work happens on your processor. Open the finished file and read it before you use it anywhere. Check two things first: whether the headings landed at the right levels, and whether any table came out as a table rather than as a run of paragraphs. That is the whole review.
Convert one page before you convert two hundred. Use the page extractor or your reader's print-to-PDF to make a two page sample, run it through, and look at the markup. Whether a document converts well is decided by how it was produced, and you learn that from two pages just as reliably as from the whole file. Sample first.
A PDF does not contain a document. It contains drawing instructions. The text layer of a page is a list of operations that say, in effect, set this font at this size, move to x=72.4 y=690.1, show these glyphs. There is no paragraph, no heading, no list and no table anywhere in the file. Those things existed in whatever produced the PDF and were discarded at export, because a PDF's job is to record appearance exactly and it does that job by throwing structure away.
So converting a PDF to HTML is an inference problem rather than a format conversion. Every heading this tool produces is a conclusion drawn from geometry. Nothing is read from a label. Knowing how those conclusions are reached tells you exactly which documents will convert cleanly and which will not, before you spend an operation finding out the hard way.
Lines come first. The opening pass groups positioned glyph runs into lines by their baseline, with a tolerance proportional to the type size rather than a fixed number of points. A fixed tolerance either merges two lines of eight point footnotes or splits a single line of thirty point display type that happens to contain a superscript. Within a line, runs are sorted by horizontal position and the gaps between them are measured:
Total and Revenue as two separate runs with no space character between them at all, and the gap is the only evidence a space was ever there.The second pass decides where paragraphs begin. Three signals are used, in descending order of reliability:
Size decides. A heading is a block set noticeably larger than the body, or a short block set slightly larger and entirely in a bold face. Body size is the median type size across the whole document weighted by character count, rather than the most common size or the size on page one, so a report whose footnotes outnumber its paragraphs still measures its body text correctly. The ratio between a block's size and that body size chooses the level: roughly 1.55 and above becomes a level one heading, 1.28 and above a level two, and anything smaller that still qualifies becomes a level three.
This is why a document typeset with one size throughout converts to a wall of paragraphs. If the author made their headings bold without making them bigger, and did not make them noticeably shorter than a body line, there is nothing in the file to distinguish them. The information was destroyed at export. No converter can recover what is not there, and that is a property of your PDF rather than a defect in the tool.
Tables are the highest-value thing to recover here, and the hardest. A table in a PDF is usually nothing more than text placed at particular coordinates, sometimes with lines drawn around it and very often without any at all. The file contains no cells. What it contains is the fact that things happen to line up, and that is the only evidence there is.
The detection here runs in two stages. First, the converter looks for runs of consecutive lines that all contain at least one column-sized gap, using the measurement taken during line building. A run of two or more such lines is a candidate region. Then the column detector examines only that region, finds the horizontal positions where text repeatedly starts across its rows, and splits on those positions rather than on the gaps in any individual line.
The two-line minimum is not arbitrary. A single line with a wide gap in it is far more often a right-aligned page number, a leader-dotted contents entry or a signature block than it is a table, and promoting those to one-row tables is how a clean export acquires forty pieces of junk markup. If the column detector disagrees with the gap detector - it finds only one column where the gaps suggested several - the region falls back to ordinary paragraphs rather than producing a table with nothing in it.
| Table style | Result | Why |
|---|---|---|
| Financial statements, price lists, spec sheets | Excellent | Wide, consistent column gaps and short cell contents. This is the case the detector was built for. |
| Tables with ruled lines and generous padding | Very good | The padding produces the gaps. The ruled lines are not read at all, which surprises people, but they are drawing operations rather than structure. |
| Dense tables with tight columns | Mixed | Neighboring columns merge into one cell. Switch Column sensitivity to Tight on the PDF to Excel tool to compare, then come back. |
| Cells whose text wraps onto several lines | Poor | Each wrapped line becomes its own row, because nothing in the file says the second line belongs to the cell above it. |
| Merged and spanned cells | Not recovered | A span exists only as an absence of text at a coordinate. Reconstructing it would be guesswork with a confident face on. |
| Tables inside a scanned page | Nothing | There is no text layer at all. Run OCR first, then convert what that produces. |
The first row of every detected table becomes a header row by default. That is a presentation decision rather than something read from the file, and it is right often enough to be the default and wrong often enough to be worth checking. Check it. Fixing it costs one edit in the output markup.
A great many PDF to HTML converters produce a file that renders correctly and is useless. They emit one absolutely positioned div per line of text, each with a pixel offset and an inline font declaration, which reproduces the page perfectly and cannot be edited, restyled, read by a screen reader, indexed usefully by a search engine or reflowed onto a phone. It looks right. It is a picture of a document made out of divs.
This converter writes semantic markup instead. What comes out is the small set of elements that carries meaning:
<h1> through <h6> for headings, at the level the size ratio indicated, optionally with an id so every section is a link target.<p> for paragraphs, with <strong> and <em> inside them where the source used a bold or italic face.<ul> and <ol> with real <li> children, the bullet or number character stripped because it becomes list formatting rather than text. An ordered list that started at seven keeps its start attribute.<table> with <thead>, <tbody>, <th> and <td>.<pre><code> for blocks set entirely in a monospaced face, so a shell transcript in a manual does not arrive as a paragraph.<hr class="ch-page-break"> at each page boundary, if you asked for those, labelled with the page number and carrying a real page break when the HTML is itself printed.No inline styles, no positioning, no font declarations per element. The output is markup you can restyle, paste into a CMS, feed to a static site generator or diff against a previous version, which is the whole reason to convert a PDF to HTML rather than just embedding it.
With Complete web page on, the file is a full document with a doctype, a charset, a viewport meta and a small stylesheet inlined in the head. That stylesheet is deliberately about forty lines: a readable measure, sensible heading scale, table borders, code styling, and a prefers-color-scheme block so the document is not a white rectangle when read at night. Nothing is referenced externally, so the file works from a USB stick with the network off.
Switch it off and you get the body markup alone, indented and nothing else. That is the version to paste into a page you already have, where your own stylesheet should own the appearance and a second doctype would be a bug.
A scan is a photograph of paper. It has no text layer, so there is nothing to read and nothing to infer structure from. A converter that produced an empty HTML file from it would be technically correct and practically the worst possible outcome, because you would believe the conversion worked and find out later. So this tool refuses, says why, and names the two things that will work.
The first is OCR, which reads the characters off the image and welds them back on as a real text layer. Convert the searchable PDF that produces and everything in this guide applies to it normally.
The second is the Pages as pictures mode on this page. Every page is rasterized at the resolution you choose and embedded into the HTML as a base64 data URI, wrapped in a figure with a caption. One file, nothing beside it. The result reproduces the document exactly, opens in any browser, needs no image folder alongside it, and paginates properly when printed.
Be clear about what that mode costs. The text in those pages is a picture of text: it cannot be searched, selected, copied, read aloud by a screen reader or indexed by anything. It is a viewer, not a document. The result screen says so every time rather than letting you discover it later. Use it when reproducing the page exactly is the point - a signed contract, a certificate, a historical scan - and use OCR when the content is the point.
Resolution, and the file size it costs. 96 dpi is fine for reading on screen. 150 dpi is a good default and roughly doubles the size of the finished file. 200 dpi is readable when printed. 300 dpi is print quality and produces an HTML file several times larger than the PDF it came from, because a base64 data URI is about a third larger than the bytes it encodes. A twenty page document at 300 dpi is not a web page any more.
The usual architecture for an online PDF to HTML converter is an upload form, a queue, a command line utility and a temporary download link. Your document crosses the internet, is written to a disk you do not control, and is retained for however long a privacy page claims. For a public brochure, fine. For a contract, a board pack, a medical report, a tender document or anything under embargo, that is a data transfer you did not intend to make.
This converter has no upload endpoint, because it has no server-side step. Your file is opened with the browser File API, parsed by a PDF engine running as JavaScript on your processor, and the finished markup is produced as a Blob your own browser downloads from itself. No queue. No temporary link. The document exists on your disk and in your RAM, and nowhere else.
One consequence follows from that. Because the extraction reads only the text layer, metadata a PDF carries outside its pages does not travel into the HTML: the author name your word processor embedded, the internal file path sitting in the title field, the software that produced it, any tracked revision information. Converting to HTML strips all of it as a side effect. That is usually exactly what you want before publishing something, and occasionally it is the thing you needed to keep.
Every file is probed as it lands, so a locked or damaged document reports at the drop zone rather than after the operation is claimed. What follows are the problems that appear in the finished markup instead, and every one of them is a property of the source PDF rather than a setting you missed.
| Symptom | Cause | Fix |
|---|---|---|
| This PDF has no text layer | It is a scan. There are no characters in the file, only a picture of them. | Run OCR on it first, or use Pages as pictures if reproducing the page exactly is what you need. |
| Everything came out as paragraphs | The document uses one type size throughout, so nothing distinguishes a heading from body text. | Nothing recoverable. Add the heading levels by hand in the output, which is still faster than retyping the document. |
| Headings landed at the wrong level | Level comes from the ratio between heading size and body size, and a document with four sizes maps onto three levels. | Search and replace the levels in the output. The order is always right even when the depth is not. |
| A table came out as paragraphs | Its columns are too close together for the gaps to register, or its cells wrap onto several lines. | Try the PDF to Excel tool with Tight column sensitivity to see whether the columns are findable at all. |
| Paragraphs are split at every line | The document is set in a narrow column and almost every line reaches the right margin, so the short-line signal never fires. | Common with two column academic layouts. Extract one column at a time with the page cropper if it matters. |
| Words are joined together | The producer emitted adjacent runs with no space characters and gaps too small to read as spaces. | Typical of files exported by design software. A search and replace on the output is the practical fix. |
| Two column pages read in the wrong order | Reading order comes from geometry, and a two column page has two vertical flows. | Lines are grouped by baseline, so columns interleave. Split the columns first, or convert to Pages as pictures. |
| Ligatures came out as odd characters | The font maps fi and fl to single glyphs and the file has no correct ToUnicode mapping for them. | A search and replace. It is a defect in how the PDF was written, and every extractor hits it. |
| The HTML file is enormous | Pages as pictures at a high resolution. Base64 is about a third larger than the bytes it encodes. | Drop to 150 dpi, or use Real HTML if the document has a text layer. |
Drop the PDF into the zone at the top of this page, choose Real HTML, decide whether you want a complete web page or just body markup, and press Convert to HTML. The conversion runs in your browser on your own processor, no account is needed for your first run, and there is no watermark or attribution on the output.
It is editable semantic markup: real heading elements, paragraphs, list items and table cells, with no inline styles and no absolute positioning. That is the whole point. Many converters emit one positioned div per line of text, which reproduces the page and cannot be edited, restyled, read by a screen reader or reflowed onto a phone. The Pages as pictures mode here is the one that produces images, and it says so on the result screen.
No. The extraction and the markup generation run in your browser on your own processor, and your document is never transmitted anywhere. Confirm it by loading this page, disconnecting from the internet entirely, and converting anyway. It still works, because there is no server-side step for it to depend on, and no converter that uploads your file could pass the same test.
Because nothing in the file distinguishes a heading from body text. A PDF stores drawing instructions rather than structure, so a heading is identified from its type size relative to the body. If the document was typeset at one size throughout and the headings were only made bold, that information was destroyed at the moment the PDF was written out. No converter can recover it. It is a property of your file rather than a defect in the tool.
Yes, when the columns are separated by clear horizontal gaps. Gaps are the whole signal. The converter looks for runs of consecutive lines whose text is split by gaps wider than a full em, then finds the positions where text repeatedly starts across those rows and splits on them. Financial statements, price lists and specification sheets convert very well. Densely packed tables merge neighboring columns, and cells whose text wraps onto several lines become several rows.
Not in Real HTML mode, and it will tell you so rather than handing you an empty file. A scan is a photograph of paper with no characters in it. Two routes out. Either run OCR on it first and convert the searchable PDF that produces, or use Pages as pictures, which embeds each page as an image in a self-contained HTML file that reproduces the document exactly but cannot be searched or edited.
Yes. Switch off Complete web page and the output is body markup alone, indented, with no doctype, head or stylesheet attached to it. That is what you want when the content is going into a page you already have. Your own CSS should own the appearance. Leave it on instead for a standalone file that opens in any browser and works from a USB stick on a machine with the network switched off.
About forty lines, inlined in the head so that nothing is referenced externally: a readable measure, a sensible heading scale, table borders, code styling and a prefers-color-scheme block so the document is legible in both light and dark mode. Nothing else. It is deliberately small, because it exists to make the file readable rather than to be a design.
Not in Real HTML mode. That mode reads the text layer and rebuilds structure from it, and extracting embedded pictures with their correct placement is a different problem with a different answer. Use Pages as pictures if the illustrations are essential, since it reproduces every page including everything drawn on it, or use PDF to JPG to pull the pages out as image files you can place yourself.
Yes. Give headings id attributes is on by default. Each heading gets a slug derived from its own text, de-duplicated if two headings share a title, so every section of a converted specification becomes a link target. Switch on Build a table of contents as well and a nav element with a linked list is written above the body.
20 files and 100 MB per batch for anonymous visitors and free accounts, and 100 files and 500 MB on CartHacker Premium. An operation is one conversion run, however many pages went into it, so converting a two hundred page report costs exactly one. Anonymous visitors get one operation per 12 hours and a free account gets two. CartHacker Premium removes the counter. The real constraint here is memory rather than policy, and a very large document is more comfortable split across two batches than forced through in a single run.
Because reading order is inferred from geometry, and a two column page has two vertical flows running down the same sheet of paper. Lines are grouped by their baseline, so the left and right columns interleave line by line, giving you the first line of one followed by the first line of the other. No marker exists. Crop the columns apart before converting if the order matters, or use Pages as pictures.
No. The file contains your content and a generator meta tag, nothing else. No logo, no banner, no trial stamp, no required attribution, and the output is free for commercial use, including client work you are billing somebody else for.
All of these run the same way: your file is read by JavaScript on your own machine, the work happens on your processor, and the result is handed back to you as a download that never existed anywhere else.
Find the apps that slow your store down, by name and in milliseconds, then answer shoppers' doubts with trust badges under Add to cart. Both are free, with no card and no access to your store admin.
Paste any page and get its three Core Web Vitals, the apps costing time, like Klaviyo or Judge.me, and the Shopify or WooCommerce fix.
Show the promises that settle doubts, from free shipping to a money-back guarantee, right under the Add to cart button. One line in your theme.
Change the link after printing and count the scans. 5 tracked codes on a free account, static codes unlimited.
Anonymous visitors get one operation per 12 hours, per network address. That is not a sales tactic, it is the only lever we have: this tool runs on your processor, not ours, so the run itself earns us nothing. An account tells us who you are, and the ceiling goes up the moment you have one. Your allowance resets in 12 h.
No credit card, no trial period, no sales call. Join with Google, GitHub, Facebook or email.
Free accounts get two operations per 12 hours, and yours reset in 12 h. Waiting costs you nothing and is a completely reasonable choice. If PDF work is a weekly job rather than a one-off, the counter is the wrong tool for you and Premium takes it off the page.
Cancel anytime. Everything you have already produced stays yours either way.