PDF to Markdown for LLMs: preparing documents for ChatGPT, Claude and RAG
Paste a PDF into a chat model and it usually works, in the sense that the model answers. Underneath, the PDF's layout noise — wrapped lines, repeated headers and footers, reading-order quirks — becomes tokens the model has to see through before it reaches the content.
Converting to Markdown first removes most of that noise at the source. This article explains where PDF noise comes from, what it costs in tokens, why single-line paragraphs matter for chunking and diffs, and how this site's LLM-optimized output mode is built for exactly this workflow.
Why LLMs choke on raw PDFs
When a chat tool accepts a PDF directly, something has to turn it into text first, and that something is usually a quick-and-generic extractor. What comes out preserves the PDF's storage artifacts: line breaks mid-sentence, hyphenation from the original justification, headers and footers repeated on every page, and column text interleaved in storage order.
Models are good at looking past this, which is why direct upload appears to work. But the model spends attention reassembling paragraphs that a converter could have delivered intact, and on long documents the waste compounds: repeated footers alone can be thousands of tokens of pure repetition.
Structured text also anchors the model's citations. When you ask a model to quote the clause it based an answer on, clause numbering and heading levels from a Markdown conversion give it stable landmarks; a wall of reflowed PDF text gives it nothing to point at.
The hidden token cost of PDF noise
Tokenizers charge by pieces of text, and PDF noise is made of pieces. A hard-wrapped paragraph costs the same characters but extra newlines; a two-page footer repeated forty times is a fixed cost per page whether or not it matters; hyphenated line breaks like "conver- sion" can split into pieces that neither match the word nor carry meaning.
The waste is not just volume, it is position. Context windows are finite, and noise at the front pushes content toward the truncation point. Documents that would fit comfortably as clean Markdown sometimes overflow as raw PDF dumps, and the model's answer quality degrades long before anything is cut off.
None of this shows up in the answer's tone, which is why it goes unnoticed. It shows up in how much of the document the model actually engaged with, and in the invoice if you are paying per token through an API.
One paragraph, one line: why wrapping matters
Traditional text tools hard-wrap output at 72 or 80 columns because that is how terminals and printed pages worked. In a Markdown file destined for a model, every one of those wraps is a potential chunk boundary in a retrieval pipeline that splits on newlines or paragraph lengths.
Single-line paragraphs make chunking trivial: a paragraph is a line, a splitter can cut on blank lines, and every chunk contains whole sentences. With hard-wrapped text, the same pipeline must first undo the wrapping, and if it does not, chunks break mid-sentence and retrieval quality drops in ways that are hard to debug.
Line-based diffs get the same benefit. When a contract revision changes one clause, a single-line-paragraph file shows exactly one changed line; a wrapped file can reflow the rest of the paragraph and bury the real change in a dozen diff hunks.
The compact profile in practice
This site's converter has an explicit LLM-optimized toggle. Enabled, it does two things: the PDF engine runs in its compact extraction profile, which prefers plain, tight text over layout-faithful verbosity, and the Markdown writer disables hard wrapping so every paragraph is one line.
The compact profile is a different trade-off, not a strictly better one. Layout faithful modes reproduce more of the page's visual structure, which is what a human reader converting for editing wants. Compact mode strips that decoration down to content and structure, which is what a token stream wants.
The toggle only affects Markdown output, and that is deliberate: HTML, RST, and LaTeX destinations are consumed by renderers that re-wrap anyway. If your destination is a model, stay in Markdown with the toggle on; if it is a human, the default is the better read.
Feeding Markdown into a RAG pipeline
Retrieval-augmented generation lives or dies on chunk quality. Markdown gives the pipeline something PDF never can: structural boundaries that are also semantic boundaries. Headings mark topics, so a splitter can chunk per section and attach the heading trail as metadata; tables arrive as intact pipe-table blocks that survive embedding as units.
The practical recipe is boring on purpose: convert each PDF to single-line-paragraph Markdown, split on headings with a size ceiling, keep the heading path with each chunk, and embed. Every step is a one-liner against a well-formed Markdown file and a fragile heuristic against a raw PDF.
Batch conversion matters here more than in interactive use. A knowledge base is dozens or hundreds of documents, and this tool converts them serially in the browser and packages results for download, with no upload step in the middle — which matters more when the documents are the kind you cannot upload.
Why conversion should happen on your machine
The documents people feed to LLMs are disproportionately sensitive: contracts, board minutes, unpublished research, client files. Handing those to a cloud converter adds a party to the data flow whose retention policy you did not write, and the convenience of drag-and-drop hides that this is an upload.
This converter runs the PDF parsing engine as WebAssembly in your browser tab. The file is read with the browser's file API, processed in memory, and written back out locally; there is no server component in the conversion path at all. You can load the page, disconnect from the network, and conversion keeps working.
That design choice is the same one that makes the tool suitable for the LLM workflow specifically: the whole point of preparing a document for a model is often to keep control of who sees it. A converter that uploads would undermine the goal one step earlier.
Limits to keep in mind
Scanned PDFs have no text layer, and no conversion profile changes that. If the source is a scan, run it through OCR software first and convert the OCR output; the converter flags pages with no extractable text instead of silently returning a stub.
Complex tables arrive simplified. GFM pipe tables cannot express merged cells or multi-level headers, so models see a flattened version. For table-heavy sources where the table is the point, verify a few rows against the original before trusting downstream answers.
And the toggle is not a quality dial for the extraction itself: compact mode changes how faithfully layout is rendered, not how correctly text is recognized. If a conversion produces garbled characters, the problem is in the source encoding, not the profile.