Convert PDF to Markdown for LLMs: what survives, and what quietly does not
Converting a PDF to Markdown for an LLM works cleanly when the PDF has a text layer and simple layout; reading order, tables and scanned pages are where the conversion silently loses meaning rather than failing.
Why Markdown became the intermediate format
A language model reads text, not layout. Markdown keeps the few structural signals that survive being flattened - headings, lists, emphasis, table pipes - and throws away the rest, which is why almost every document-to-LLM pipeline now passes through it. It is a lossy conversion chosen deliberately: the parts it loses are the parts a model cannot use anyway.
The text layer is the whole question
A PDF produced by Word, LaTeX or a browser stores its words as text and converts almost perfectly. A PDF produced by a scanner or a phone camera stores a photograph of those words, and every text-based converter extracts nothing at all from it - not an error, an empty result. Both end in .pdf and look identical on screen. Select a sentence with your cursor: if it highlights, it will convert.
Reading order is the failure nobody notices
A PDF stores position, not sequence. A two-column paper, a sidebar, a footnote or a caption can extract in an order no human would read them in, and the output is still valid Markdown - just with sentences from different columns interleaved. That output then chunks into passages mixing unrelated text, and retrieval returns them confidently. Check a sample from the middle of a document, not the first page, before converting a library.
Tables are where converters differ most
Simple grids survive as pipe tables. Merged cells, nested headers and tables spanning a page break are where tools diverge sharply, and a table flattened into a run of numbers is worse than a table dropped - the numbers are still retrievable, just no longer attached to their headings. If your documents are mostly tables, test that specifically rather than trusting an overall accuracy figure.
Markdown is not the end of the pipeline
Converting to Markdown produces one long document; retrieval needs passages. The chunking that follows decides retrieval quality at least as much as the conversion did, and a clean Markdown file chunked badly retrieves worse than a rough one chunked well. RAG Converter goes straight from your file to sized, overlapping chunks with a manifest, so there is no intermediate file to get that step wrong on.