Markdown vs HTML for LLM Context (Measured on 3 Pages)

Before an LLM reads a web page, something decides whether it sees the words or the markup around them. I measured markdown vs HTML for LLM context on three real pages today, token by token, and the choice moved the bill by 4x to 34x. The smaller format also drops things you will miss at the worst moment, so I tested that too.

The verdict

For reading tasks (summarizing, question answering, classification, extracting facts and quotes), convert to markdown first. Same content, 75 to 97 percent fewer tokens on my test set. For acting tasks (form fills, logins, multi-step flows), markdown strips the attributes agents need, so give them the DOM or its accessibility tree instead. For retrieval-augmented generation over pages where tables and link structure carry meaning, cleaned HTML can beat markdown outright.

	Raw HTML	Markdown
Tokens per page (measured)	32,574 to 71,680	1,750 to 8,168
Boilerplate	Ships with the page	Removed at conversion
Tables	Exact rows, columns, attributes	Often flattened to prose or a link
Form fields	name, type, value, hidden inputs	Visible labels only
Link targets	Preserved	Preserved in GFM output
What an agent can do	Read and act, if pruned	Read; act only on visible text
Failure mode	Cost and distraction	Silent structure loss

Markdown vs HTML for LLM context: the token bill

Three pages, three shapes of web content. Raw HTML fetched today (2026-10-16) with curl; markdown produced by a trafilatura-class extraction pass, the same one most scraping tools run; tokens counted with OpenAI’s o200k_base tokenizer, the encoding behind GPT-4o-class models.

Page	Raw HTML tokens	Markdown tokens	Saved
Wikipedia: Web scraping	71,680	7,458	89.6%
Python docs: json module	32,574	8,168	74.9%
NPR news article	58,839	1,750	97.0%

Same words, smaller suitcase. Anthropic’s 200K-token context window fits about three raw Wikipedia articles; converted, about 26. I won’t quote a dollar figure, because prices move; the per-page math multiplies fast across a crawl, and the pricing guide covers it: LLM web scraping costs.

Where the tokens actually go

The NPR page is the caricature. Half its bytes sit inside <script> and <svg> elements, and inline SVG alone accounts for 38 percent. A regex that strips script and style tags takes real bites out of pages like that.

Wikipedia barely bothers with scripts: 7 percent of bytes. Its bloat is prose furniture instead, the navigation text, site notices, and footer repeated on every article of the site. The raw HTML carries 475 anchor tags; the markdown keeps 211 links. The NPR headline appears nine times in the source (title tag, Open Graph, Twitter card, JSON-LD, the h1); markdown says it once.

So the junk is two different species. One is machine payload you can pattern-match away. The other is human-readable boilerplate that only a readability pass recognizes as skippable, which is why every serious converter runs one.

What markdown silently drops

Take the Python docs’ json module page. It contains a genuine data table, the JSON-to-Python conversion table (object to dict, array to list, string to str). After conversion, that table survives as exactly one sentence: a pointer to the “JSON-to-Python conversion table”, linked to an anchor whose table no longer exists. All 8,168 markdown tokens contain no table structure; their only pipe characters are shell pipes inside code examples. A model reading this page cannot answer “what JSON type maps to a Python list?” from the document in front of it.

Forms are worse. I ran a standard login page through html2text, a widely used converter. Out came two words: “Username” and “Password”. The form’s action and method, the hidden CSRF token, the input names a submission needs: gone. The text looks complete. Nothing about it is.

The most careful published numbers agree. A Stagehand team benchmark (1,440 calls across 10 pages, one Claude model) measured both formats on reading and acting:

• Reading accuracy: raw HTML 92 percent, markdown 80 percent.
• Tokens per correct answer: markdown 1,992, raw HTML 5,094.
• Acting tasks (click, fill, submit): markdown 70 percent, an indexed interactive DOM 97 percent.
• Login-input tasks answered from markdown: 0 of 9.

Markdown won the economics decisively and lost the mechanics. Neither loss shows up in a side-by-side eyeball of the text.

When HTML wins

Three cases, in order of how often I hit them.

Anything with a submit button. Agents fill forms from attributes: name, type, value, the options inside a select. The middle ground is the accessibility tree, the browser’s flattened view of the page (roles, names, states, values) built for assistive technology. In the same benchmark it read at 88 percent and acted at 83 percent, at 2,708 tokens per correct answer, between markdown and raw HTML on both axes.

RAG where structure is the answer. The HtmlRAG paper (arXiv 2411.02959, Renmin University and Baichuan) makes the strongest published case against reflexive conversion. Their argument: plain-text conversion discards table structure, code boundaries, and link semantics, and models already understand HTML from pretraining. Their pipeline cleans real web HTML (which averages over 80,000 tokens per page, more than 90 percent of it CSS, JavaScript, and comments) down to about 6 percent of original size, then prunes it. That cleaned HTML met or beat plain-text and markdown baselines across six QA datasets. Note what they did not do: feed raw pages to the model. The enemy was never HTML; it was unclean HTML.

You need byte-exact fidelity. Quotes for evidence, code blocks with indentation, legal text: conversion rewrites, and rewrites drift. Keep the source for anything you might be cross-examined on.

The conversion pipeline

Convert once at fetch, and keep the raw response on disk so you can re-convert when a task needs it. Tools that return markdown by default now cover the whole spectrum: hosted APIs (Jina Reader, Firecrawl), crawl frameworks (Crawl4AI), local libraries (trafilatura, html2text); crawlers built for model consumption make the same trade, and AI web crawlers compares them. Some sites even publish an llms.txt so consuming models can skip the markup entirely, though adoption is still thin. And when the reader at the other end is a coding assistant, the same conversion rules apply; feeding pages to Claude walks that workflow end to end.

Tool note. The markdown in my measurements came from magpie scrape <url> --page-format markdown, a local CLI that runs this exact fetch-then-clean pass. It also produced the flattening example above: the Python docs table came through as a link, not a table. Every converter in this category is lossy in the same neighborhood; test against your target pages.

Reading tasks dominate most pipelines, and markdown’s failure mode is at least visible when you look for it. If your pipeline feeds pages to a coding agent for extraction work, the choice is not markdown vs HTML but extractor vs selector; that comparison lives in LLM extraction vs CSS selectors.

FAQ

Do LLMs understand raw HTML? Yes. Models saw enormous amounts of it during pretraining, and in the benchmark above raw HTML slightly beat markdown on reading accuracy, 92 to 80 percent. But it cost 2.5 times as many tokens per correct answer, and raw pages ran 4 to 34 times the converted size.

How many tokens does a typical web page cost? There is no typical. My three pages ranged from 32,574 to 71,680 raw tokens and 1,750 to 8,168 converted; the 75 to 97 percent spread is the only honest answer. Measure your own targets before budgeting.

Should a RAG pipeline store HTML or markdown? Both, if storage is cheap. Retrieve and answer from markdown for cost, then re-read the cleaned HTML when a question depends on tables or link structure. The HtmlRAG authors showed cleaned, pruned HTML can even replace markdown without quality loss.

Why can’t my agent fill a login form from markdown? Markdown keeps visible text and drops attributes. Input names, types, values, hidden CSRF fields, the form’s action and method: all gone. In one benchmark, agents answered 0 of 9 login-input tasks from markdown. Use the DOM or accessibility tree for anything with a submit button.

What is an accessibility tree? The browser’s flattened description of a page for assistive technology: roles, names, states, and values without markup noise. Interactive agents use it because it keeps what buttons and inputs actually are, at about half of raw HTML’s tokens per correct answer in the benchmark above.

The rule I use

Convert at ingest, keep the HTML on disk, and pick per task: reading gets markdown, acting gets the tree, RAG gets markdown until an answer proves it lives in a table, then cleaned HTML. Measure before you commit, because the spread is enormous. My three pages took ten minutes to count. At a 1,000-page-a-day crawl running at the Wikipedia numbers, feeding models raw HTML instead burns about 64 million input tokens a day, before pricing a single one.