Markdown vs HTML for LLMs: Why the Token Counts Differ
The advice "feed Markdown to LLMs, not HTML" is everywhere in AI engineering posts, usually with a vague "Markdown is more efficient" justification. This article explains where the difference actually comes from, what it means for cost and context windows, where HTML still keeps something Markdown drops, and how to check the gap on your own pages with tiktoken.
Where the difference comes from
Feed the same web page to a model twice, once as raw HTML and once as Markdown, and the Markdown version is the same content condensed by stripping markup, scripts, styles and ad scaffolding. Two effects compound:
1. Markdown syntax is more compact than HTML syntax
For the same semantics, Markdown uses fewer characters:
| Semantic | HTML | Markdown |
|---|---|---|
| Heading | <h1>Title</h1> (14 chars) | # Title (7 chars) |
| Bold | <strong>X</strong> (18 chars) | **X** (5 chars) |
| Link | <a href="u">X</a> (17 chars) | [X](u) (6 chars) |
| List item | <li>X</li> (10 chars) | - X (3 chars) |
On each of these constructs, the Markdown markup is a fraction of the HTML markup, while the words inside stay the same. Real pages often add attributes (classes, IDs, inline styles) to their tags, which widens the gap further.
2. HTML carries chrome that Markdown extraction strips
The bigger savings come from content extraction. Raw HTML includes:
- Site navigation
- Ad scaffolding and tracking scripts
- Sidebar widgets and related-content cards
- Footer with extensive link farms
- Inline styles, classes, data-attributes
- Hidden elements and ARIA wrappers
On ad-heavy news sites, the chrome can dwarf the article body. On leaner sites like Wikipedia, chrome is smaller relative to content, so the gap narrows, although the markup itself still costs more than Markdown's.
GPT-4o cost math
GPT-4o pricing as of writing (verify on OpenAI's current pricing page):
- Input: $2.50 per 1M tokens
- Output: $10.00 per 1M tokens
The page goes in as input, so the input rate is the one that matters here. Per page, input cost = page tokens × $2.50 / 1,000,000. Compute it once with the HTML token count and once with the Markdown count of the same page: the difference is what the markup costs you on every call.
Scale math
For a pipeline, multiply by volume: pages per day × average tokens per page × $2.50 / 1,000,000 gives the daily input cost. Run it with your HTML average and with your Markdown average.
For a single-developer side project ingesting a few pages a month, the difference is negligible; pick whichever is easier. The cost grows linearly with volume, so for any scale that matters commercially, the per-page gap becomes a real budget line.
Context window implications
Cost isn't the only concern. Context windows are finite. Context capacity varies by model and account. Check current limits and count the actual prepared input, including conversation history and response headroom.
If you're stuffing pages into a context window for a long-form task, every token of markup you strip is room for content: the smaller each page, the more pages fit in the same window.
For RAG specifically, this means more relevant chunks per query budget. For long-document tasks, more documents per call. For agent loops with iterative reasoning, more breathing room before context-window pressure forces summarization.
Quality implications
Token efficiency is the obvious benefit. The often-overlooked one is answer quality. Models reasoning over Markdown produce better answers than the same models reasoning over HTML for the same content. Why:
- Less noise: nav cruft, scripts, styles all distract attention. The model wastes tokens (in its reasoning, not your bill) on figuring out what's content vs chrome.
- Cleaner structure: Markdown headings are unambiguous. HTML headings are sometimes
<h2>, sometimes<div class="heading">, sometimes<p><strong>styled to look like a heading. Markdown forces semantic clarity. - Better retrieval: for RAG, embedding quality on Markdown tends to be higher because the embedded text is content, not markup.
We discuss the broader argument in best format for LLM input. For PDFs specifically, see how to measure PDF vs Markdown token counts: same principle, different format.
Honest caveats
Where HTML might preserve more useful info than Markdown:
- Tables with rowspan/colspan: Markdown can't represent these natively. HTML keeps the structure; Markdown either flattens or duplicates cells.
- Custom inline styling: a
<span style="color: red">warning marker has no Markdown equivalent. The semantic might matter for certain analyses. - Forms and interactive elements: HTML preserves form structure; Markdown drops it.
- Microformats and structured data: schema.org JSON-LD, RDFa, Microdata. Markdown drops these.
For most LLM use cases (Q&A, summarization, RAG, agent reasoning), none of these matter. For specialized cases (web data extraction, accessibility analysis, form filling), keep the HTML.
Practical recommendation
For any LLM workflow consuming web content:
- Convert HTML to Markdown before feeding to the model. Use a quality converter: our URL-to-Markdown tool, Firecrawl, or Jina Reader. See what each URL to Markdown tool is for.
- For RAG pipelines, use the RAG-specific variant that emits chunked output ready for embedding.
- Track token counts of your inputs (use our token counter or tiktoken locally). Knowing your token bill is the first step to managing it.
- Don't optimize for HTML preservation unless you have a specific use case that requires it. The default should be Markdown.
The savings compound across cost, context window, and answer quality. There's no scenario where naive HTML beats Markdown for general LLM workloads, only edge cases where specific HTML semantics matter enough to justify the token tax.