When you feed a document to a language model, the format you choose changes both what it costs and how well the model understands it. Markdown wins on both counts, and the margin is larger than most people expect. This page has the measured comparison and a conversion pipeline that works.
The short case
Markdown carries the same structure as HTML — headings, lists, tables, emphasis, links — in roughly a quarter of the tokens. It preserves the structure plain text throws away. And it is heavily represented in training data, so models treat its conventions as meaningful rather than as noise.
The measured comparison
The same short section of content, expressed four ways:
| Format | Tokens | Structure kept | Verdict |
|---|---|---|---|
| HTML (as emitted) | ~105 | All, plus noise | Wasteful |
| Markdown | ~28 | All | Best |
| Plain text | ~24 | None | False economy |
| JSON-wrapped | ~48 | All, verbosely | Only if you need machine parsing |
That ratio is conservative. The example is hand-written HTML with modest class names. A real page carries navigation, a header, a footer, a cookie banner, inline scripts, tracking pixels and a comment section — on a typical article, the content is under 10% of the HTML.
⚠️ Plain text is the false economy
Stripping to plain text saves about 15% against Markdown and discards every structural signal. The model can no longer tell a heading from a sentence, cannot see where a list begins, and receives a table as a run of numbers.
It also degrades your chunker, which uses headings and paragraph boundaries to split sensibly. You save a few tokens and pay for it twice.
Why models handle Markdown so well
Three reasons, and the first is the substantial one.
Training data. Markdown is the native format of technical documentation, README files, forum posts, issue trackers, static site generators and a large share of technical writing on the internet. Models have processed enormous quantities of it, so ## at the start of a line is not an odd character sequence — it is a heading, learned from millions of examples.
Token efficiency in the markers themselves. Markdown's syntax is mostly single characters that already exist as common tokens. ##, -, ** and | cost almost nothing. HTML tags cost several tokens each and appear twice per element.
It is legible as prose. A Markdown document read as a flat character sequence — which is what the model receives — still reads as a document. HTML read the same way is punctuated by tag noise between every phrase.
Tabular data specifically
Tables deserve their own analysis because the format difference is largest here.
The gap widens with row count, because JSON's per-row overhead is constant while CSV's is zero after the header. At a thousand rows, JSON can cost more than twice CSV for identical data.
✅ Which table format when
- Under ~30 rows → Markdown table. Readable, aligned, and the model reasons about it well.
- Over ~30 rows → CSV. The alignment padding stops paying for itself and CSV scales better.
- Nested or irregular data → JSON. It is the only one of the three that can express nesting.
- Very large tables → do not send them. Query the data and send the result.
Converting HTML properly
The order of operations matters more than the converter you pick. Strip first, convert second — running a converter over a full page produces Markdown containing the navigation, footer and cookie banner, which is smaller noise but still noise.
For production use, a readability-style extractor — the same technique browser reader modes use — does step 5 far better than a selector guess. It scores elements by text density and link ratio to find the actual article.
What to keep and what to drop
| Element | Keep? | Reasoning |
|---|---|---|
| Headings | Yes | Structure for the model and the chunker |
| Lists | Yes | Enumeration is semantically meaningful |
| Tables | Yes | Relationships are lost without them |
| Bold and italic | Yes | Cheap, and marks emphasis |
| Code blocks | Yes | Signals not-prose, which matters |
| Blockquotes | Yes | Marks quoted material as quoted |
| Link text | Yes | Usually carries meaning |
| Link URLs | Usually not | Expensive; rarely used in reasoning |
| Images | Alt text only | Alt text is content; the URL is not |
| Class and id attributes | No | Pure overhead |
| Inline styles | No | Pure overhead |
Link URLs are worth singling out. A documentation page with fifty links can spend several hundred tokens on URLs the model will never reason about. Converting [refund policy](https://example.com/legal/policies/refunds?ref=nav) to plain refund policy keeps the meaning and drops the cost.
Keep them when the model genuinely needs to cite or follow sources — a research assistant, for instance. Drop them for question answering over a corpus.
Two things to get right
Escape user content in prompts
If document text is interpolated into a prompt, Markdown headings inside that text can read as instructions to the model.
Delimit untrusted content explicitly — XML-style tags work well because they are unambiguous and models follow them reliably:
Fence code blocks with the language
The language tag costs one token and meaningfully improves how the model handles the block, particularly when a document mixes several languages.
When Markdown is the wrong choice
| Situation | Use instead |
|---|---|
| You need machine-parseable output | JSON, with a schema |
| Deeply nested data | JSON or YAML |
| Large tabular datasets | CSV |
| Layout itself is the information | An image, to a vision model |
| Exact whitespace matters | A fenced code block |
The distinction that resolves most cases: Markdown for input, JSON for output. You want the model to read something legible and structured, and to write something your code can parse without ambiguity.
Converting HTML to Markdown?
Paste HTML and get clean Markdown instantly — runs entirely in your browser, so it works on internal pages you would not paste into a web service.
Open the HTML to Markdown Converter →Summary
- Markdown costs about a quarter of HTML's tokens for the same content, and far less on real pages.
- Plain text is a false economy — it saves ~15% and loses all structure.
- Models handle Markdown natively because it saturates their training data.
- CSV beats JSON by roughly 2× for tabular data, and the gap grows with rows.
- Strip before converting — navigation and boilerplate are most of a web page.
- Drop link URLs unless the model needs to cite them.
- Delimit untrusted content so its headings cannot read as instructions.
- Markdown in, JSON out.
Frequently Asked Questions
Why is Markdown better than HTML for LLM input?
It carries the same structure — headings, lists, tables, emphasis, links — in a fraction of the tokens. HTML spends most of its bytes on tags, class attributes and closing elements that convey nothing the model needs. On real web content the difference is commonly 4 to 10 times.
Should I strip all formatting and send plain text?
No. Plain text is marginally cheaper than Markdown and loses the structure that tells the model what is a heading, what is a list item and where a table's columns are. That structure is worth its small token cost — chunkers use it too, so stripping it degrades retrieval as well as comprehension.
How should I send tabular data to an LLM?
CSV for large tables, Markdown tables for small ones. JSON repeats every key on every row, so it costs roughly twice as much for the same data. Markdown tables read well and stay aligned; CSV is the most compact and scales better past a few dozen rows.
Do models actually understand Markdown syntax?
Yes, thoroughly. Markdown is heavily represented in training data — documentation, README files, forum posts, technical writing — so models have seen enormous quantities of it and treat its conventions as meaningful structure rather than incidental punctuation.
What should I strip when converting HTML to Markdown?
Scripts, styles, navigation, headers, footers, cookie banners, advertisements and comment sections. On a typical article page these are the majority of the HTML and none of the content. Removing them before conversion often cuts the token count by more than the conversion itself does.