Markdown Funeral: HTML, Replacing Markdown Overnight?

For the past few days, all platforms have been circulating the same story: “Markdown is dead.” “The strongest AI team switched to HTML.” “Stop writing Markdown.” “The Markdown era is over.” All headlines much shorter than the article they claim to summarize.

The source is a piece by Thariq, a Claude Code engineer at Anthropic, called The Unreasonable Effectiveness of HTML (https://x.com/trq212/status/2052809885763747935, published 2026-05-08).

I read it three times, because I wanted to confirm one thing: did he actually say that?

He didn’t. Not once.

1. What Thariq actually said

Look at the use cases he lists:

• specs and planning documents
• code reviews and PR artifacts
• design prototypes and animations
• reports for your boss or your team
• single-use editors (reprioritizing 30 Linear tickets, tweaking feature flags, tuning prompts with side-by-side preview)

What do they have in common? They are all artifacts. One-shot deliverables. Shown to a human once, thrown away, or uploaded to S3 as a shareable link.

In the middle of the piece, Thariq writes this verbatim:

“I’m a little bit afraid that people will read this article and turn it into a /html skill or something. While there might be some value in that, I want to emphasize that you don’t need to do much to get Claude to do this. You can just ask it to ‘make a HTML file’.”

This is a restrained author. He’s flagging — explicitly — not to turn his personal preference into doctrine.

So why did everyone hear “Markdown is dead”?

2. How a restrained essay grows into a radical slogan

It’s not Thariq’s problem. It’s the transmission chain’s problem.

An essay called Unreasonable Effectiveness of HTML, dropped into the traffic machine, becomes something else: “Anthropic engineer says drop Markdown.” “Claude team quietly switched.” “Killed my three-year default.” The article’s actual scope, tradeoffs, and the author’s own disclaimer — all gone.

Because the first form is an argument. The second is a click. The first asks you to read 3,000 words. The second only asks for three seconds.

This isn’t a new pattern. Every restrained technical piece, dropped into the traffic mechanism, eventually becomes its opposite — “In these few cases, X works better than Y” travels through three hands and arrives as “Y is dead.”

3. Let me first concede HTML’s wins

Before going further, this needs to be clear:

Every use case Thariq lists, HTML is the right choice.

• Single-use editors? Yes.
• PR artifacts with readable inline diff annotations? Yes.
• Button animation prototypes with sliders to tune parameters? Yes.
• Weekly status reports for your boss, incident reports for leadership? Yes.
• Drag-to-reorder 30 tickets across columns? Yes.

The shared property: take long content humans don’t want to read, turn it into something readable in three seconds. HTML renders nicely, supports interaction, and is easy to share — all true.

If this essay ended here, I’d just be saying “Thariq is right, you all read it wrong.” But that isn’t the deeper point.

4. Two questions that got confused

The real argument is not “Markdown vs. HTML.”

The real argument is that two questions got confused:

Question A: “Should the artifact I’m handing a human look prettier?” Answer: HTML is often the right call. Thariq’s whole article answers this one.

Question B: “What format should I use for the knowledge I’m accumulating, for AI to read and write across years, across model versions, as a source of truth?” Answer: That is not the same question.

When “the strongest AI team abandoned Markdown for HTML” went viral, it smuggled Question B’s answer in as if it were Question A’s.

Source of truth and rendering layer are not the same thing. The first is where content lives, in what structure it is stored. The second is how that content is shown to a human. HTML often wins at the rendering layer. At the source layer, it loses to Markdown for five reasons.

5. Why the source layer stays Markdown

Content should live in a clean house

Open a raw HTML file. Then open a raw Markdown file. Different experience entirely. In HTML, every line is wrapped in tags, attributes, indentation, whitespace. The content is caught in a net. In Markdown, # Title is three characters — in HTML it’s <h1></h1> plus possibly class, id, style.

That’s before diff noise — Thariq himself, in his FAQ, admits “HTML diffs are noisy and hard to review compared to Markdown.”

That’s before token cost — he says HTML is 2-4x the tokens of Markdown.

That’s before the content/markup blur — in Markdown you can see which words are important and which are structure. In HTML that line disappears.

Content should live in a clean house. Markdown is the house. HTML is the showroom.

Rendering should be handled by something built for it

Converting Markdown to HTML is a two-decade-old deterministic problem. Pandoc, Hugo, Obsidian Publish — same input, same output every time, no tokens, auditable, offline-capable.

LLMs at this task are slower, more expensive, more variable. But LLMs do win at a different scene: one-shot, interactive, fancy-beyond-what-conventional-renderers-can-do artifacts — the prototypes, sliders, custom editors from Thariq’s article. That’s the LLM’s win. It is not the markdown-converter’s battleground.

Separate the two things: daily rendering goes to deterministic tools, one-shot artifacts go to the LLM.

Obsidian, Logseq, every Markdown editor — they’ve been doing the daily rendering layer for over two decades. They just haven’t been invested in to Thariq’s demo level. What’s missing isn’t replacing Markdown with HTML. What’s missing is building the rendering layer.

Ten-year readability

Markdown’s syntax has barely changed since 2004. #, *, -, []() — a Markdown file from twenty years ago reads exactly like one written today. Any human can pick it up.

Pure HTML is also backward-compatible — <h1> still renders fine after thirty years. But LLM-generated HTML is rarely pure HTML. It carries inline styles, JS hooks, framework-flavored classes, arbitrary nesting. Renders today. Three years from now, when a framework rotates or sandbox policies tighten, no guarantees.

When you’re accumulating a knowledge base meant to last a decade, you’re betting on lowest-common-denominator stability. On that metric, Markdown wins outright.

The training-data irony

When LLMs are trained, HTML tags are very often treated as noise. Many extraction and cleaning pipelines strip boilerplate, remove tags, leave only plain text — because plain text is what training needs to learn from.

And now we’re telling users: wrap your clean Markdown content in HTML tags so the LLM can read it better.

The next training run strips those tags out again.

The loop is the argument. No need to be angry. Just look at it.

The author’s cost curve is not yours

Thariq is on the Claude Code team at Anthropic. He structurally has “infinite tokens.” His format preference is downstream of his cost curve.

You aren’t.

When he says “in 1M context, HTML being 2-4x the tokens isn’t really noticeable,” that’s true for him. For you — a Pro account user who hits the quota wall every month — that line is an ad for a luxury good.

Thariq isn’t being dishonest. He just never claimed to be giving you advice about your token economics.

6. A thought experiment

Picture this:

Take your entire Obsidian vault. Or your Notion workspace. Or your Logseq graph. Convert every single note from Markdown to HTML storage.

What becomes of it?

It becomes a big website.

It is not a knowledge base. It is a blog’s drafts folder. Every file, raw, opens to a forest of tags. Diffs are unreadable. Search results show 30 lines of <head> before any content. Every LLM read costs 2-4x tokens. Every concept rename means matching closing tags carefully.

That is not a knowledge home. That is an artifact inventory.

7. Closing

The real argument is not Markdown vs. HTML.

It is whether source of truth and rendering layer should be separated.

The answer is: yes.

Thariq’s actual point, in his own article, is the same — he is saying “at the rendering / artifact layer, HTML is better than Markdown.” He never said the source layer should change too.

Markdown can carry everything because it tries to replace nothing.

It is not the prettiest display format. It just won’t betray your decade.

Next time someone forwards a “Markdown is dead” headline, ask them one question:

Source, or render?

If they can’t answer, they didn’t read the article.