Why converting a PDF loses structure, and what to do about it

What is actually inside a PDF

A word processor document is a tree. It records that a run of text is a level-two heading, that these paragraphs belong to that section, that these cells form a table with three columns. The visual appearance is derived from that structure at display time.

A PDF is the opposite. It is a set of drawing instructions: place this glyph, from this font, at this size, at these coordinates on this page. The structure that produced the layout is not saved. It was used to compute the positions and then discarded.

This is not an oversight in the format. PDF was designed in 1993 to guarantee that a document looks identical on every device and every printer, and the way to guarantee that is to specify appearance exactly and leave nothing to be re-derived. It succeeded completely. The cost is that a PDF knows where every character sits and nothing about what any of them mean.

So converting a PDF to Markdown is not extraction. It is inference: reading the geometry back and guessing what structure would have produced it. A good converter guesses well. No converter can do better than guess, because the answer is genuinely not in the file.

The one exception: tagged PDFs

A tagged PDF carries an additional structure tree, added for accessibility so a screen reader can announce headings and read table cells in order. When it is present and correct, much of the guesswork disappears.

In practice it is rarely both. Tagging is optional, most PDF producers do not add it, and a great many that do add it produce tags that disagree with the visible layout — every paragraph marked as a heading, or a table tagged as a sequence of paragraphs. A converter that trusted bad tags would produce worse output than one that ignored them.

If you control how the PDF is produced and you care about conversion quality, exporting a properly tagged PDF from Word or LibreOffice is the single most useful thing you can do. If you are converting documents that arrive from elsewhere, assume they are untagged.

How structure is inferred from geometry

The rules any spatial converter uses are broadly the same, and they are worth knowing because each one implies a failure mode.

First, establish a unit. The body text height — the most common font height in the document, weighted by how many characters are set at it — becomes the yardstick, so the rules work the same whether the document is set in 9pt or 14pt.

Then measure everything against it. Text sharing a baseline is one line. Lines separated by a small vertical gap are one paragraph; a larger gap starts a new one. Text set noticeably larger than the body is a heading, and how much larger decides the level. Rows of text whose fragments line up on shared horizontal positions are a table. A tall empty vertical band down the middle of a page means two columns, so the reading order should go down one and then down the other.

This converter uses roughly these thresholds, measured in multiples of the body height:

Every failure follows from a rule

Read that list again as a list of assumptions and the errors stop being mysterious.

• Headings styled by weight or colour rather than size are invisible to a size threshold. A document whose headings are bold 11pt over 11pt body text has, geometrically, no headings at all.
• Tables with merged cells break the shared-x-position test, because a merged cell sits at a position no other row uses. The rows stop aligning and the block stops being recognised as a table.
• A table cell whose text wraps onto a second line looks like two rows, one of which has a hole in it.
• Generous line spacing can push lines of one paragraph past the paragraph-break threshold, splitting it. Tight spacing between paragraphs can merge them.
• A three-column layout, or two columns of unequal width, or columns interrupted by a full-width figure, all defeat a mid-page gutter test.
• Text set as an image — a logo containing words, a chart with labels, a scanned page — has no glyphs at all, so there is nothing to position and nothing to read.

Which documents convert cleanly

The pattern across all of it: single-column documents produced by a word processor, with headings that are visibly larger than the body text, simple rectangular tables, and real text rather than pictures of text.

That describes most reports, papers, manuals, theses, contracts, meeting minutes and internal documentation — which is to say most of what people convert. It does not describe magazines, brochures, annual reports with designed infographics, forms, invoices with complex tables, or anything scanned.

Getting a better result from a difficult document

A few things genuinely help, in rough order of how much difference they make.

• If you can regenerate the PDF, export a tagged one — or better, skip the PDF and convert the original document instead. Converting a PDF made from a Word file is always worse than converting the Word file.
• Split a document that mixes layouts. Convert the ten pages of prose separately from the four pages of tables, rather than fighting one conversion that has to handle both.
• Extract a stubborn table on its own. A table that fails inside a 60-page document often converts correctly when it is the only thing on the page.
• Expect to fix headings by hand in a document that styles them by weight. It is a search-and-replace pass, not a re-typing job.
• For a scan, run text recognition first. There is no shortcut: no parser can find text that was never encoded as text.

Always read the output

The failure mode that costs people real time is not a conversion that visibly breaks. It is one that quietly drops something — a footnote, a final table row, a line that fell outside the detected column — and produces clean, plausible Markdown with a hole in it.

Skim the converted Markdown against the original before you rely on it, and pay particular attention to tables, to anything numeric, and to the last few lines of each page. That is where quiet losses concentrate.