Attaching a PDF to an API call feels like the efficient move. One file, no preprocessing, the model handles the rest. Then the bill arrives and a 100-page report that contains maybe 30,000 tokens of actual text has consumed somewhere between 70,000 and 100,000 tokens.
That isn’t a billing error. It’s what PDF support actually does under the hood, and understanding it is the difference between a document pipeline that scales and one that quietly burns money.
Why a PDF is expensive
PDF is a layout format, not a document format. It describes where marks go on a page — this glyph at these coordinates, that line at those — and it does not reliably record that a run of text is a heading, that four columns of numbers are a table, or that a two-column page should be read down the left side before the right.
That missing structure is a problem for a language model, so providers solve it with vision. Anthropic’s PDF support, for example, processes each page as both an image and an extracted text layer — the image preserves layout, charts, stamps, and handwriting; the text layer enables precise citation. It’s a genuinely good design, and it’s why the token cost per page lands around 1,500–3,000 tokens depending on density.
Compare that to the same content as clean Markdown. Running real samples through OpenAI’s o200k_base tokenizer:
| Content | As Markdown | As PDF input | Ratio |
|---|---|---|---|
| Dense page, ~500 words of prose | ~550 tokens | 1,500–3,000 | 3–5x |
| Mixed page: heading, prose, small table | ~190 tokens | 1,500–3,000 | 8–16x |
The ratio is worst for the pages that look sparse to a human. A page with a heading, three paragraphs, and a small table is cheap as text and costs the same as any other page as an image, because image cost tracks page count, not information density. A report full of whitespace, headers, and footers is where the multiplier gets ugly.
At scale the arithmetic stops being abstract. That 100-page report at 1,500 tokens per page is 150,000 tokens per run. As Markdown it might be 20,000. On a model at $3 per million input tokens, that’s $0.45 versus $0.06 — every single time you process it.
Why Markdown works well for LLMs
Markdown hits a sweet spot that neither raw text nor PDF manages:
- Headings carry hierarchy.
##tells the model this is a section boundary. Plain text extraction loses that entirely — you get a line that happens to be short. - Tables stay tabular. A Markdown pipe table survives as a grid. The same table naively extracted from a PDF often becomes a stream of numbers with no indication of which column they belonged to, which is exactly the kind of error that produces confident wrong answers.
- It’s dense. No layout instructions, no font descriptors, no image payload — just content and a handful of structural characters.
- Models were trained on mountains of it. Markdown is the native dialect of READMEs, docs, and forum posts. It’s familiar territory.
There’s also a retrieval benefit if you’re building RAG: clean headings give you natural chunk boundaries. Chunking a mangled PDF text dump usually means splitting mid-table.
The four converters worth knowing
The open-source tooling consolidated in 2025–2026 around four options. They are genuinely different tools, not four versions of the same thing, and picking wrong is the usual reason people conclude “PDF conversion doesn’t work.”
PyMuPDF4LLM — the fast, light default. Excellent on native (digitally generated) PDFs, runs fine CPU-only, minimal dependencies. It does not do OCR, so scanned documents come back empty. If your PDFs are clean and machine-generated, start here and stop here.
MarkItDown (Microsoft) — fastest of the group on simple digital PDFs, by a wide margin, and handles many other formats besides. The tradeoff is structural depth: it’s roughly 50–100x faster than the heavier tools but discards structure that downstream retrieval often depends on. Good for bulk ingestion where approximate text is enough; poor when tables matter.
Docling (IBM Research) — built for production RAG pipelines and the strongest option for complex tables. In head-to-head comparisons on financial reports and scientific papers, it preserves merged cells and multi-level column groupings that lighter parsers lose. It’s slow and heavier to deploy. If your documents are financial statements or anything where a misread table is a real problem, this is the one.
Marker (Datalab) — accuracy-first, uses Surya OCR, and runs on GPU, CPU, or Apple MPS. Handles PDFs, images, DOCX, PPTX, XLSX, HTML, and EPUB. On scientific PDFs with heavy mathematics and complex layouts it generally matches or beats Docling on quality while being faster on GPU. It wants a GPU to be practical.
A pattern that works well in production: run the fast path by default, escalate selectively. MarkItDown or PyMuPDF4LLM for clean digital PDFs, Docling for anything with serious tables, Marker in a GPU pool for the academic subset. Route on the document, not on a global setting.
When you should not convert
Conversion is not always the right call, and articles that sell it as universally correct are wrong.
Keep the PDF when the visual content is the content. Charts without underlying data tables, diagrams, scanned signatures, stamps, handwritten annotations, form layouts where position carries meaning — all of this survives as pixels and dies as Markdown. A vision-capable model looking at the page image will outperform any text extraction.
Keep the PDF when you need page-level citations. If your product has to point a user at “page 47,” the native pipeline that retains page boundaries and offsets gives you that for free. Reconstructing it after conversion is fiddly.
Keep the PDF for one-off analysis. If you’re asking three questions about one document, the engineering time to build a conversion pipeline costs more than the tokens. The economics only flip at volume or on repeated processing.
Convert when you’re processing documents repeatedly, running a RAG pipeline, working with text-dominant documents, or watching a token bill grow faster than your usage.
A hybrid approach often wins: convert the text and tables to Markdown for retrieval and reasoning, and keep page images available for the specific pages where a chart or diagram needs to be inspected.
Check the difference yourself
The honest way to size this up for your own documents is to measure rather than trust a rule of thumb — density varies enormously between a legal contract and a slide deck exported to PDF.
Convert one representative document, paste the Markdown into our free token counter, and compare that number against roughly 1,500–3,000 tokens per page for the PDF path. That single comparison usually settles the question in about a minute, and everything runs locally in your browser, so the document never leaves your machine.
FAQ
Does converting a PDF to Markdown lose information?
Yes, some — anything purely visual. Charts, images, diagrams, signatures, and complex form layouts don’t survive as Markdown. Text, headings, lists, and (with a good converter) tables do.
Which PDF to Markdown converter is most accurate?
For complex tables, Docling. For scientific papers with heavy math, Marker. For clean digital PDFs where speed matters, PyMuPDF4LLM or MarkItDown. There’s no single winner — accuracy depends on document type.
Can I convert a scanned PDF to Markdown?
Only with a tool that does OCR. Marker (via Surya) and Docling handle scans; PyMuPDF4LLM does not and will return nothing useful for an image-only PDF.
Is Markdown better than plain text for LLMs?
Generally yes, for a negligible token cost. The structural markers preserve hierarchy and tables that plain extraction flattens, which improves both retrieval and answer accuracy.
How many tokens does a PDF page use?
Roughly 1,500–3,000 tokens per page when sent as a PDF to a vision-based document API, depending on density. The same content as Markdown is typically 3–16x cheaper, with the largest savings on sparse pages.
Want to see what your documents actually cost before you send them? Try the free token counter. For background on how any of this is measured, read what LLM tokens are, and if you’re wrestling with document size, what a context window really gives you.
Related Tools:
- Token Counter - Compare token counts before and after conversion