Feeding a document to a language model is now one of the commonest reasons to convert a PDF, and it wants something different from every other reason. You do not need the layout, the pagination or the fonts. You need the words, in the right order, with enough structure that a heading is recognisable as one.
Markdown, in one line
It is plain text, so nothing has to be unpacked or parsed. And a leading # costs one character while preserving the document's outline. That combination is why it has become the default for this job.
| Format | Why it does or does not work |
|---|---|
| Markdown | Plain text, structure preserved, negligible overhead |
| Plain text | Loses every signal about how the parts relate |
| Word (.docx) | A ZIP of XML, something has to convert it back to text first |
| Works where the tool handles it well; you cannot see what it extracted | |
| HTML | Structure preserved, but the markup can outweigh the content |
Reading order matters more here than anywhere
This is the part worth taking seriously. On a two-column PDF, a naive extractor reads across the page and interleaves the columns.
A person notices instantly, because the result is gibberish. A language model does not. It receives something that reads like prose and means something else, and it will answer questions about the scrambled version fluently and confidently.
That is the failure mode to watch for: bad extraction does not produce an error, it produces a plausible wrong answer. Academic papers, reports and newsletters are all commonly two-column, and all commonly fed to models.
So look at the extracted text before you send it. The Markdown converter detects columns and reads each in turn, and says when it found them, but the ten seconds you spend reading the output is what actually protects you.
What to strip before sending
Conversion is the last point at which the document is entirely under your control, which makes it the right moment to decide what leaves.
Personal data you do not need. Names, addresses, account numbers, dates of birth. Usually irrelevant to the question you are asking and trivial to delete from Markdown first.
Repeated furniture. Page headers, footers, confidentiality notices and "page 4 of 37" markers repeat on every page, cost tokens and mean nothing.
Anything you are not entitled to share. A document being easy to convert does not make it yours to send to a third-party service. Client material, material under NDA and personal data belonging to other people are all worth a moment's thought, and the thought is unavoidably yours.
Practical notes
Chunk long documents at headings. If you are building a retrieval system, splitting on heading boundaries beats splitting every N characters, a chunk that begins mid-sentence is much harder to retrieve usefully. Preserved headings are what makes that possible, which is another argument for Markdown over plain text.
Tables do not survive well. A PDF does not record that cells belong to a table, so reconstructing the grid from the text layer is not generally possible. If your document is mostly tables, extract them as a spreadsheet and describe them separately.
Figures are lost entirely. If the meaning of your document lives in its charts, text conversion loses it, and it is better to know that before you draw conclusions from what the model says.
If the conversion produced nothing
Your PDF is a scan, a photograph of a page with no text in it. See what that means for the ten-second check and what the options actually are.