Thariq Shihipar (from Anthropic) published The Unreasonable Effectiveness of HTML last month. Simon Willison's reframing of the argument is the one that landed:
With current context window sizes and faster, cheaper models, defaulting to Markdown outputs may no longer be the best strategy. Asking Claude for an explanation in HTML means it can drop in SVG diagrams, interactive widgets, in-page navigation and all sorts of other neat ways of making the information more pleasant to navigate.
— Simon Willison
I agree with this pattern, especially when we try to represent complex or dense information.
Why Markdown was the default
Markdown became the default for AI output for good reasons. Text-only formatting. Small text (and token) footprint. Universal rendering. Streaming-friendly. Diff-friendly. None of those reasons have disappeared. But faster, cheaper, and more capable models changed the game:
- Context windows used to be small. Every token was expensive. They are now in the hundreds of thousands to millions. The token cost of HTML over Markdown is no longer load-bearing, depending on if you are on subscription or pay-per-token model.
- Streaming chat used to be the primary surface. Now agentic outputs land as files, artifacts, dashboards, and reports — often opened in a browser by default.
- Models used to be unreliable at structured output. Frontier models now produce valid, well-formed HTML by default, with much better styling.
- Browsers used to be one rendering surface among many. They have become the dominant one for technical reports.
The default made sense as it was the most efficient and versatile format. But several of those constraints stopped binding sometime in the last few months.
What HTML unlocks beyond Markdown's ceiling
- Rich content (for free!) - Everything required to build and render complex layouts and interactions, without additional dependencies, is available in HTML+CSS+JS. Accessible CDN endpoints, templates, fonts, icons etc are available everywhere for free.
- In-page navigation — anchored TOC, jump links, sticky headers — viable for fifty-section reports (no React, no bundler required).
- Inline SVG diagrams — architecture views, state machines, sequence flows — that beat any ASCII or Mermaid approximation.
- Interactive tables and charts - Tables with columns that can be sorted and filtered, and charts that can be interacted with in real-time.
- Interactive widgets — collapsible sections, filterable tables, sortable columns, hide/show toggles.
- Real layout — color, hierarchy, columns, callouts, grids — not just emphasis.
- Embedded interactive previews — charts, mini-dashboards, before/after comparisons.
None of these require any additional tooling. The models and agents can easily produce them inline.
What we have been doing in recent engagements
In the last few client engagement assessments, we have shifted to HTML-first outputs for complex flow analysis and architecture views. When the artefact has to surface a dependency graph, a request flow across services, or a 30-service decomposition map, HTML's visual hierarchy and interactivity cut comprehension time dramatically. The client opens the report in their browser and they can easily understand the flow and can provide much more relevant feedback.
Markdown still does the work it's best at — narrative sections, glossaries, structured-text comparisons. Markdowns are still part of the source repositories. It will continue to be the best format for PRs, commit messages, and quick notes.
Markdown or HTML? Why not both?
Defaults are worth re-adjusting when the constraints and economics change. HTML is no longer expensive to generate, harder to render or slower to consume.