Guides to converting PDFs well

Converting a PDF is easy. Getting a result you can rely on takes knowing what the format does and does not record, where every converter has to guess, and what to check before you trust the output. These guides cover the questions that come up most, and none of them resolves to “so use our converter”.

The one idea underneath all of them

A PDF does not contain headings, paragraphs, lists or tables. It contains glyphs at coordinates. The structure that produced the layout was used to compute those positions and then discarded, which means converting a PDF to Markdown is not extraction but inference: reading the geometry back and deducing what structure would have produced it.

Every converter does this, ours included, and no converter can do better than infer — the answer is genuinely not in the file. Once that is clear, the errors stop looking arbitrary. A heading that came out as a paragraph was styled by weight rather than size. A table that collapsed had merged cells. A page that reads as nonsense had two columns. Each failure traces back to a rule, and a rule you know about is one you can work around.

The guides here fall into three groups. Some explain the inference itself and the failure modes that follow from it — lost structure, interleaved columns, collapsed tables, and what recognition can recover when there is no text to read at all. Some are about the file you get back and the edits worth making before you keep it. The rest are about destinations — a note vault, a retrieval pipeline, a bibliography, a document long enough that it needs taking apart first — which place quite different demands on the same Markdown.