PDF vs Markdown for AI: which saves tokens, which reads cleaner (2026)

You drop a 40-page market report into the chat and ask for a summary. The model takes a beat, then hands back something half-right and oddly fixated on the footer that repeats "CONFIDENTIAL — Q3 2026" forty times. The table on page 12 — the one with the actual numbers — came back as a single run-on line. And the context window is already two-thirds full, on one document.

The information was all there in the PDF. The container just spent your tokens carrying the wrong things.

This is the part of "use AI on your documents" that nobody warns you about: the format you feed the model decides how much it costs and how well it reads, before the model does any thinking at all. For that job, Markdown and PDF are not close.

The two ways a PDF reaches a model

A model can't read a PDF the way you do. The file has to become something the model ingests — and there are only two paths, each with its own tax.

Path 1 — extracted to text

A tool pulls the text out of the PDF and hands the model a stream of characters. When the extraction is clean, the token count is roughly the same as Markdown of the same words. The problem is that real-world PDFs almost never extract clean:

• Headers and footers repeat on every page — the document title, the page number, the confidentiality stamp — so a 40-page report carries 40 copies of furniture the model has to read past.
• Multi-column layouts interleave, because extraction follows the PDF's internal storage order, not the human reading order.
• Tables linearize into nonsense — the grid that made the numbers legible collapses into a run-on line, and the model reads the wrong value with full confidence.
• Hyphenation and line breaks from the fixed page width get baked in as literal characters mid-word.

None of that noise was information. All of it costs tokens, and worse, it dilutes the model's attention across junk.

Path 2 — read as page images

The other path skips text entirely: each page is rendered as an image and handed to a vision-capable model. This preserves layout — the model sees the table as a table — but the price is steep and fixed:

A full page rendered as an image costs on the order of several hundred to well over a thousand tokens, depending on the model and resolution — and that cost is the same whether the page is dense or nearly blank.

So a 40-page report can spend tens of thousands of tokens just being seen, before a single question is answered. For a page that's mostly text, you paid image prices to deliver text content. For a page that's mostly a diagram, the image path is the only one that works — which is exactly when PDF earns its cost (more on that below).

Why Markdown reads cleaner to an LLM

Markdown wins the token math, but the bigger win is comprehension.

Markdown is plain text with a few characters of structure. There's almost no overhead between the information and the tokens — it sits close to the floor for anything text-shaped. And the structure it does add is the structure the model wants:

## Q3 Revenue by Segment

| Segment     | Revenue | YoY  |
|-------------|---------|------|
| Enterprise  | $4.2M   | +31% |
| Mid-market  | $1.8M   | +12% |

Net revenue retention held at **118%**, driven by the
enterprise expansion motion described in the prior section.

That table survives as a table. The heading is unambiguously a heading. The model was trained on millions of documents shaped exactly like this — READMEs, wikis, docs, forum posts — so ## reads as hierarchy, | reads as a grid, and **118%** reads as emphasis. Hand the same content to the model as extracted PDF text and the structure is gone; hand it as a page image and you paid image prices for it.

The practical effect: for retrieval, summarization, and Q&A over a document — the bread-and-butter of "feed AI my files" — Markdown gives the model fewer tokens to chew and cleaner structure to navigate. It's the efficient default, and it's not a close call.

When PDF is still the right format

Markdown wins the input job. That doesn't make PDF wrong — it makes it built for a different job, and that job is real:

• A human is the final reader and the layout is the point — the printed leave-behind, the paginated board pack, the brochure. Fixed layout is a feature there, not a tax.
• Signatures and filings — esignature and regulatory workflows are PDF-native. The legal team archives a frozen-at-submission document, not a Markdown file.
• The seven-year archive copy — a file on disk outlives any URL or chat session.
• Scanned or diagram-heavy originals — when the meaning lives in the visual (a complex financial statement, an architectural drawing, a handwritten form), a vision model reading the page image captures spatial relationships that text extraction would flatten. Here the image-token cost buys you something.

The honest split is by direction of travel. Document going into a model → Markdown, almost always. Document going to a human who needs fixed layout or a signature → PDF. Most of the "PDF is better" cases are really "a person needs this frozen," not "a model reads this better."

Getting clean Markdown out of a document

When the input job is the one you're doing, the goal is clean Markdown with as little of the PDF tax as possible:

1. Export from the source, not the PDF. If you still have the Google Doc, Notion page, or notebook, export straight to Markdown or HTML and skip the lossy round-trip entirely.
2. If you only have the PDF, convert — don't paste. Use a PDF-to-Markdown converter or a vision model to transcribe it. Raw copy-paste follows the PDF's storage order, which is rarely the reading order.
3. Fix the tables first. They're the first thing to mangle, and a garbled table is worse than none — the model reads the wrong numbers confidently.
4. Strip the repeated furniture. Delete the headers, footers, page numbers, and stamps that extraction duplicates on every page. Each copy spends tokens and dilutes attention.
5. Verify the structure reads as hierarchy. Headings as # levels, lists as real list items, code in fenced blocks — that's what lets the model navigate instead of reading one long paragraph.

The format you actually hand a person

Here's the turn most format comparisons miss. Markdown wins going into the model. But the thing the model gives back — a report, a one-pager, a dashboard — eventually has to reach a human. And for that, neither Markdown nor PDF is the natural answer.

Raw Markdown looks like code to a non-technical reader: ## and | on screen, not a finished page. A PDF freezes any interactivity into a flat screenshot and forwards as a heavy file that forks into everyone's Downloads folder. The format that renders as a real page, keeps interactivity alive, and forwards as a link is HTML — which is the case for HTML over PDF on the human-delivery side, the mirror image of the token argument here.

So the full path looks like this: feed the model Markdown, and when it hands you HTML back, share that as a link rather than re-flattening it into a PDF. Seen whole, the three formats aren't rivals but a sequence — author in Markdown, deliver in HTML, freeze to PDF only when something needs a signature. The last mile is a URL someone opens — sharing an HTML report with one person covers the channel choice, and if the output came out of a Claude or ChatGPT artifact, the export-and-share path is its own short walkthrough.

The container you choose at each step is quietly deciding the cost and the quality — Markdown to spend fewer tokens going in, a private HTML link to read as finished coming out.