You upload a 20-page PDF to your AI chat, ask two questions, and the free plan says you've hit your limit. That isn't bad luck. It's often the format.
This guide compares Markdown vs PDF for LLM input: what the model actually receives from each, how many tokens that costs, and why the difference grows once you chunk documents for search. You'll also see the case where the PDF is the better choice, and how to check the numbers for your own model.
What an AI app actually receives from a PDF
A PDF reaches the model as extracted text, and often as an image of every page as well. Markdown reaches it as text only. When an app sends page images, they're where most of the extra tokens come from.
PDF is a print format. It stores where each glyph sits on a page, not which words form a paragraph. An AI app has two ways to read it, and many apps use both at once.
The first is text extraction. Software pulls the characters off the page in roughly the order they appear. The second is vision. The app renders each page as a picture and sends that too, so the model can see charts and layout. Anthropic's PDF support docs describe exactly this for Claude: each page is converted into an image, and the extracted text goes along with it.
Markdown skips both problems. It's already plain text, with structure written into it as
# headings, - list items and | table rows. The model gets the words and their roles, nothing else.The token math for one page
In our worked example, a 500-word page is about 667 tokens as Markdown. Sent as text plus a page image, it's about 2,235 tokens on a standard-resolution model and about 3,381 on a high-resolution one. That's roughly 70% and 80% less for the Markdown version.
Here's how those numbers fall out. A common rule of thumb is that a token is about three quarters of an English word, so 500 words is about 667 tokens. That part is the same in both formats.
The page image is the extra. Claude's vision docs price an image at one token per 28 x 28 pixel patch. Render a US Letter page at 150 dpi and you get 1275 x 1650 pixels, or 2,714 patches. Standard-tier models downscale anything above 1,568 tokens, so the page costs about 1,568. The high-resolution tier (Claude 4.7 and later) allows up to 4,784 tokens per image, so the full 2,714 count.
So the page costs about 667 + 1,568 = 2,235 tokens on a standard-tier model, and 667 + 2,714 = 3,381 on a high-resolution one. Two caveats keep this honest:
- Tokenizers differ. Claude's glossary says Claude 4.7 and later produce about 30% more tokens for the same text than earlier models. The text share grows a little, the image share doesn't, and the conclusion holds.
- Input paths differ. The savings only appear when the app sends page images. Apps that send extracted text alone save far less on tokens, though they still gain everything in the next section.
Even text-only extraction is heavy
Anthropic's PDF docs give another useful figure. For Claude on Amazon Bedrock's Converse API, a 3-page PDF uses about 1,000 tokens in text-only mode and about 7,000 with full visual understanding. Same document, seven times the input.
Extraction noise you pay for twice
Text pulled out of a PDF carries repeated headers, footers, page numbers, split words and flattened tables. You pay tokens for that noise, and the model spends attention ignoring it. Markdown conversion removes most of it before the model sees anything.
In practice, these are the usual offenders:
- Running headers and footers. "ACME Corp, Annual Report 2025, Page 14" repeats on every page. On a 40-page report that's 40 copies of a line nobody asked about.
- Page numbers and legal lines. "Confidential. Do not distribute." adds tokens and adds nothing.
- Hyphenation. "dri-" on one line and "ven" on the next tokenize worse than "driven", and can confuse search.
- Tables. A grid becomes a run of numbers with no column names. The model has to guess which figure belongs to which quarter.
None of this is the model's fault. It's reading exactly what it was given.
Reading order breaks on multi-column pages
Two-column layouts are where raw extraction gets things most wrong. Text is read across the page by line position, so lines from both columns interleave. A good Markdown conversion keeps each column's text together in reading order.
Academic papers, newsletters and many reports use two columns. When sentences from the left and right columns alternate, the model gets text that reads like a broken transcript. The model shouldn't have to untangle it, and you shouldn't pay for the confusion. Do check converted reading order on complex layouts, though. No converter gets every page right.
Why Markdown chunks better for RAG
Search systems split documents into chunks before indexing them. Markdown headings give the splitter clean places to cut, so each chunk covers one topic. Fixed-size cuts through raw text often slice a section in half.
This matters for cost as much as quality. A chunk that mixes the end of "Pricing" with the start of "Refunds" gets retrieved for both kinds of question, so it eats context space twice. Clean, topic-sized chunks mean you can send fewer of them per question.
Markdown also keeps tables as tables. A pipe table survives chunking with its header row intact, so a retrieved chunk still says which number is "Q3 revenue". That's the practical case for PDF to Markdown for AI pipelines: structure you'd otherwise lose stays in the text.
When to send the PDF instead
Send the PDF page when the answer depends on what the page looks like: a chart, a diagram, a photo or a visual layout. For text, lists and tables, convert to Markdown first.
Be fair to the PDF here. Vision models can read a bar chart that text extraction turns into nothing. If your question is "what does the trend in Figure 3 show", the page image is worth its tokens. Smaller input isn't automatically better input.
The good news is that you rarely need every page as an image. Convert the document, ask your text questions against the Markdown, and attach only the one or two pages with the chart. That mix keeps most of the savings and loses none of the answers.
How to convert a PDF and check the savings
Open LLMiser, drop the PDF on the page and press Convert. You get editable Markdown with headings, lists and tables, plus a rough token estimate, and you don't need an account.
A few settings help you reduce LLM tokens further:
| Profile | Best for |
|---|---|
| Standard | Reading and checking the result |
| Clean | Pasting into a chat |
| Compact | The fewest formatting tokens |
| RAG-ready | Chunking for search and retrieval |
LLMiser also reads scanned PDFs. Text pages are read directly, and pages that are only pictures go through text recognition, up to 100 scanned pages per file. You can convert up to 20 files in one batch and download them all as a ZIP.
Then paste only the sections your question needs. That last step often saves more than the conversion itself. To know your real number, send the same question both ways and compare the input token counts your provider reports. LLMiser's estimate divides characters by four, which is fine for ranking inputs but isn't a bill.
Frequently Asked Questions
Does Markdown really use fewer tokens than a PDF?
Usually, when the AI app also sends page images. In our worked example, a 500-word page drops from about 2,235 tokens to about 667, around 70% less. Apps that send only extracted text save less, but Markdown still removes noise and keeps tables readable.
Why does a PDF cost more tokens than its text?
Because many apps send an image of each page alongside the text, so the model can see charts and layout. On Claude, each page image costs up to about 1,568 tokens on standard-tier models and up to 4,784 on high-resolution ones. Repeated headers, footers and page numbers add further tokens.
Will converting to Markdown lose information?
It can. Charts, photos and visual layout don't survive as text. Headings, lists and tables come through, though complex layouts are worth a quick check. For a chart-heavy page, keep that page as a PDF or image and convert the rest.
Is Markdown better than plain text for LLMs?
Usually, yes. Plain text drops structure, so a table becomes a run of numbers and headings look like any other line. Markdown keeps that structure for a handful of extra characters, which helps both the model and any chunking step.
How do I measure the savings for my own model?
Run the same question with the original PDF and with the reviewed Markdown, then compare the input token counts your API or app reports. Note the model, its price on that date and whether page images were sent. Check that the answer is just as good.
Can LLMiser convert scanned PDFs?
Yes. LLMiser reads text pages directly and runs text recognition on pages that are only pictures, up to 100 scanned pages per file. Very small print and handwriting can come out with errors, so check numbers that matter.
Try it on your heaviest PDF with the free converter, then follow how to measure savings for your model.