Is HTML the New Standard for AI Output? An Anthropic Engi...

Markdown has long been the default format for AI-generated content from large language models. This seems so natural that most people never question why—but the reason is straightforward: LLMs are fundamentally text generators, and Markdown allows basic formatting like headings, lists, bold text, and code blocks using plain text. It's low-cost, highly compatible, and supported by mature toolchains, making it the obvious choice.

However, Thariq, an engineer on Anthropic's Claude Code team, recently proposed a different view. In a May 8, 2026, article titled Using Claude Code: The Unreasonable Effectiveness of HTML, he argues that Markdown is no longer sufficient and HTML should become the new standard for AI outputs. The post garnered over a million views, nearly 9,000 likes, and 11,000 bookmarks on the day it was published. Many, including Simon Willison (co-founder of Django and a well-known developer blogger), publicly reconsidered their default use of Markdown, sparking widespread discussion on Hacker News. Of course, skepticism remains, but Thariq's argument is well-documented and deserves serious consideration.

Thariq's Logic: When AI Writes, Why Use a Format Designed for Humans?

Thariq's starting point is easy to grasp. Markdown was designed by John Gruber in 2004 with one goal: to let humans quickly write HTML-like structures in plain text. In essence, Markdown is a simplified HTML—sacrificing much expressiveness for faster human input. It lacks side-by-side layouts, interactivity, inline SVG charts, color coding, and animations.

This trade-off made perfect sense when humans were the primary writers. But Thariq questions whether the assumption of "fast human writing" still holds when AI becomes the author. AI doesn't need quick input; it can output thousands of tokens per second. Instead, it requires a format that fully expresses intent—and HTML, as the native language of browsers, naturally supports what Markdown cannot.

To prove this, Thariq didn't just write an article; he built a showcase site (thariqs.github.io/html-effectiveness) featuring 20 AI-generated single-file HTML examples across nine work scenarios: exploration and planning, code reviews, design systems, interactive prototypes, charts and illustrations, presentations, research and learning, reports, and custom editing interfaces. This covers most documentation types developers and tech teams encounter daily.

The Three Reasons HTML Wins: Beyond 20 Examples

Reviewing these 20 cases reveals that HTML's advantages boil down to three categories. Understanding these categories is more useful than memorizing individual examples, as it helps you assess your own work scenarios.

Category 1: Information is inherently two-dimensional, and Markdown forces it into one dimension, losing clarity. Examples like side-by-side code comparisons, diff annotations, module relationship diagrams, design color palettes, weekly reports, and incident timelines fall here. This content requires horizontal comparison or global scanning, but Markdown only allows serial, top-to-bottom viewing. You mentally reconstruct spatial relationships when flipping between sections. HTML renders directly into two or three columns, enabling instant comparisons.

Category 2: Content requires interaction for comprehension; static text descriptions are inherently limited. This includes animation sandboxes (with adjustable easing curves), clickable multi-screen prototypes, real-time demonstrations of consistent hashing rings, and prompt template debuggers with live previews. In these cases, Markdown isn't just "weaker"—it's incapable. An interactive visualization and a textual description of it differ in communication efficiency by orders of magnitude.

Category 3: HTML is the native language for the content; using Markdown adds an unnecessary layer of abstraction. For design systems with color palette renders, component state displays, or clickable slideshow prototypes, HTML isn't just a "better format"—it's where the content lives. Rendering design tokens as color blocks is far more intuitive than listing hexadecimal codes; showing component states directly is more effective than describing hover effects in text. Using Markdown here forces a detour through dimensionality reduction and mental reconstruction.

Notably, Thariq's examples of custom editing interfaces (like task boards or feature flag editors) introduce an interesting pattern: users interact via HTML, then export results to Markdown or JSON for agent consumption. HTML serves as the interaction layer, not the final output—a point that hints at future solutions.

However, Thariq's Claim Is Too Absolute

To be clear, Thariq focuses on a narrow scenario: "AI-generated final products for human reading," such as PR descriptions, technical reports, concept explanations, or design review documents. He isn't suggesting HTML for agent-to-agent intermediate results or version-controlled documents, where Markdown or plain text remains more practical due to machine readability and lightweight nature.

Within his defined scope, HTML's expressiveness indeed offers structural advantages. But as an immediate actionable recommendation, "HTML is the new Markdown" faces two unavoidable issues today.

First, cost. A rich HTML file with inline CSS, JavaScript, and SVG can be 5–10 times more token-heavy than equivalent Markdown. With current API pricing, this isn't negligible, especially for high-frequency use cases.

Second, speed. More tokens mean longer generation times. In interactive scenarios needing instant feedback, waiting for AI to produce a full HTML file with CSS and JS creates a noticeable lag compared to Markdown.

Thariq himself addresses this through engineering practices—he's written about prompt caching. Claude Code's framework leverages high cache hit rates, where static CSS/JS parts of HTML files are cached, so the model only generates variable content. This reduces actual token costs significantly. But this requires sophisticated framework design, not something an average user or developer gets out of the box.

Crucially, these constraints are temporal, not structural. Token costs and generation speeds are declining rapidly, with order-of-magnitude improvements every six months. The "HTML is too expensive and slow" argument holds today but may not in a year or two.

A Useful Analogy: Why Excel Survived Google Sheets

This brings us to an analogy: Excel survived the web era not because it's more powerful than Google Sheets, but because it's more stable in constrained environments—local computation, low-latency handling of large datasets, a complete VBA macro ecosystem, and seamless integration with local file systems. Google Sheets excels in collaboration and distribution but can't beat native apps in performance-sensitive scenarios.

Similarly, Markdown is like Excel—limited but efficient, lightweight, offline-friendly, version-control friendly, with a mature toolchain. HTML is like Google Sheets—more expressive but with performance overhead and environmental dependencies.

This analogy has two layers. First, just as Excel and Google Sheets coexist in different scenarios, Markdown and HTML will likely complement each other rather than replace one another.

Second, more importantly, Excel's survival hinges on performance advantages stemming from hardware and network constraints. As these constraints diminish, web apps gradually encroach on its territory (a trend already underway). Likewise, Markdown's core advantages are token efficiency and generation speed. If these constraints continue to fade rapidly, the argument for Markdown's efficiency will weaken.

The Ultimate Solution: Neither HTML Nor Markdown?

Thariq points in the right direction, but HTML itself may not be the endpoint. After all, HTML is designed for human browsers, carrying decades of legacy baggage—cross-browser compatibility, backward compatibility, complex rendering models. AI-generated documents don't need any of this.

A more likely outcome is the emergence of an "AI-native" output format that combines HTML-level expressiveness with Markdown-like generation efficiency. Several directions are converging here:

1. Structured data with front-end rendering separation. Models output semantic structures (e.g., JSON), while rendering logic is fixed in client-side templates. This minimizes model-generated content but achieves rich final displays. Claude Artifacts and ChatGPT Canvas essentially follow this path—models maintain a stateful document object instead of regenerating full HTML each time, offering far higher token efficiency.
2. Template-filling models. AI fills variable slots in predefined HTML templates rather than generating entire files from scratch. This approximates Markdown's cost structure while yielding near-handcrafted HTML quality. Under current constraints, this is perhaps the most practical intermediate approach.
3. A more distant possibility: a new semantic format standard. Something akin to what XML attempted but didn't fully achieve—semantic structure with rendering instructions, yet much lighter than HTML. As agent collaboration scales, demand for such a format will grow, and someone will build it.

Thariq's pattern of using HTML as an interaction layer with an "Export" button converting to machine-readable formats already hints at this direction: input/output in lightweight formats, presentation in rich formats, connected via explicit conversion interfaces. The "ultimate solution" may well standardize this pattern.

Conclusion

Thariq's core observation is correct: Markdown's design assumption of "fast human writing" no longer holds in AI-generated document scenarios, and HTML offers structural advantages in expressiveness. His 20 examples demonstrate this convincingly across common developer documentation needs.

But as an immediate recommendation, "HTML is the new Markdown" is too absolute until cost and speed constraints fully dissolve. A more accurate take: HTML shows the direction for AI document output, but current best practices involve scenario-based choices—use HTML for final products needing interactivity and visual richness; stick with Markdown for lightweight, parseable intermediate formats. They complement rather than replace each other.

Looking further ahead, neither Markdown nor HTML may be the final answer. The true "ultimate solution" should stem from first principles of AI document generation—optimizing not for "fast human writing" or "browser rendering," but for "efficient AI generation, rich presentation, and direct human readability." This format doesn't exist yet, but its contours are emerging in products like Claude Artifacts and ChatGPT Canvas.

Thariq's original article: https://x.com/trq212/status/2052809885763747935