Thariq Shihipar (Claude Code, Anthropic) posted nine words — "HTML is the new markdown" — and broke thousands of AI workflows overnight. The argument isn't aesthetic: HTML gives agents SVG diagrams, interactive widgets, in-page navigation, and inline annotations that flat markdown structurally cannot. The counterargument (slower to generate, harder to diff, bad for version control) is real but mostly applies to the wrong use cases.
Thariq Shihipar, engineering lead for Claude Code at Anthropic, posted nine words to X: "HTML is the new markdown." The post got 8,689 likes, 1,116 retweets, and 11K bookmarks. Simon Willison — who has been writing about markdown and AI since the GPT-3 era — said it made him publicly reconsider his three-year default. That kind of reaction doesn't happen for incremental takes.
The companion site at thariqs.github.io/html-effectiveness/ shows 20 self-contained HTML files across 9 categories of work where HTML structurally outperforms markdown. These aren't hypothetical — Thariq uses them in his actual Claude Code workflow.
Markdown became the AI output format of choice during the GPT-4 era for a good reason: context windows were small, every token mattered, and markdown compresses information efficiently. Plain text with minimal structure was the rational choice when you were paying for every byte and hoping it fit in 8K tokens.
That constraint is gone. Context windows are now measured in millions of tokens. The bottleneck isn't compression — it's comprehension. The question shifted from "will it fit?" to "will it communicate?"
"Markdown was optimized for a world that no longer exists. We kept the habit after the constraint disappeared."
The structural advantages aren't cosmetic:
The PR review use case is the clearest demonstration. The prompt Thariq suggests: "Help me review this PR by creating an HTML artifact that describes it. Focus on streaming/backpressure logic. Render the actual diff with inline margin annotations, color-code findings by severity..." The result is a navigable document with the diff embedded and findings attached to specific lines — something a markdown list fundamentally cannot produce.
HTML takes 2–4× longer to generate. For long planning documents, that latency is real. HTML also doesn't diff cleanly in version control — a single structural change can cascade through dozens of lines. And HTML stored in a repo is hostile: harder to read in a terminal, harder to grep, harder to update by hand.
These aren't strawmen. They're good reasons to keep markdown for:
The counterarguments don't apply to ephemeral review artifacts, one-shot reports, or analysis outputs that aren't committed anywhere — which is exactly the category where HTML wins.
If the output lives in a repo or needs to be human-edited: markdown. If the output is consumed as a document — read once, acted on, discarded: HTML. The mistake isn't using markdown; it's using markdown by default without asking whether HTML would serve the reader better.
"The format should serve the reader, not the workflow. Markdown serves the workflow. HTML serves the reader."
"Markdown was optimized for a world that no longer exists. We kept the habit after the constraint disappeared."
"The format should serve the reader, not the workflow. Markdown serves the workflow. HTML serves the reader."
"Eight thousand likes for nine words. That's not engagement. That's recognition."