How Markdown Went From One Guy's Blog Tool to

There's a file on your computer—or maybe in your Claude interface, or your Obsidian vault, or your README on GitHub—that ends in .md. You probably didn't think too hard about what that stood for. It stands for Markdown. And Markdown came from one person: John Gruber, a guy who wrote a blog about Apple and got tired of writing HTML by hand.

That origin story is almost aggressively mundane. And yet here we are, in 2026, where the two asterisks Gruber picked for bold text have become something close to the default formatting language of artificial intelligence. Every major LLM outputs Markdown by default. Every claude.md system prompt file, every Obsidian note, every GitHub README—they're all living inside a convention that one blogger built in 2002–2004 because he hated writing <em> tags.

The Vergecast just put Gruber and tech executive Anil Dash in a room to talk through the whole arc of this story, and it's worth sitting with, because the Markdown story turns out to be a surprisingly clear lens on how the web actually works—and who gets credit when it does.

The philosophy that made it stick

Before getting into the history, it's worth being precise about why Markdown worked when other attempts at simplifying HTML didn't. Gruber's competitor in the early 2000s was Textile, made by the late Dean Allen. It was cleaner than raw HTML. Sophisticated people used it. Gruber liked it. But he still built something different.

The distinction he draws is sharp: most lightweight markup languages were optimized for writability—making it easy to type the right characters. Gruber went the other direction.

"The readability was more important to me than the writability—that it should be that maybe the overriding goal of it is you should be able to print it out in Markdown format and hand it to somebody who's never heard of Markdown, never used a command line, and they can just read it and they would totally understand what you mean."

This wasn't a small design choice. It meant sticking to ASCII characters even when fancier Unicode options were available. It meant that **bold** would look like emphasis even to someone who'd never opened a terminal. The document could be read before it was rendered. That's the whole trick.

Dash's description of what this felt like at Gawker and Huffington Post in the early days makes the impact concrete: writers who'd been enduring HTML could suddenly produce formatted posts that looked, in the raw text, basically like an email. "They said that explicitly," Dash recalled on the show. "They're like, 'Oh, this is like normal. We don't feel like nerds when we see this.'"

That's a product insight, not a technical one. The people who needed to write weren't developers. They weren't going to learn a syntax. They were going to keep writing the way they already wrote—and if the tool met them there, they'd use it without noticing they'd adopted a new standard.

The slow burn, then the two inflection points

Here's where the Markdown story gets more complicated than "good idea goes viral." Gruber is direct in the Vergecast conversation about something that often gets softened in retrospect: 2004 to 2010 was slow. Disappointing, even. He believed in the format entirely; adoption didn't match his conviction.

The two sites that changed this were Stack Overflow (2008) and GitHub (2009). The interesting detail Dash offers is that Markdown wasn't a foregone conclusion at either platform—it was argued over. Stack Overflow was a community of developers, the exact people you'd expect to embrace a lightweight syntax. There were still real debates about whether users would know it, whether HTML mixing would cause problems, whether it was worth the overhead of explaining it.

GitHub's approach was different and, in retrospect, more aggressive: GitHub Flavored Markdown became the default. You didn't opt in. You were just writing in it now, and the README you were about to submit was going to be rendered that way whether you'd read the docs or not.

Gruber's read on why this worked: "It's not that you need it, it's that once you start using it, you're not going to want to go back. It really is one of those things where you have to use it for a while before you see the appeal." GitHub made that forcing function happen for a generation of developers who had the "I know HTML, I don't need this" reaction. Once they were inside it, they became the people spreading it.

The overcorrection problem

The Vergecast conversation gets genuinely interesting when it turns to Gruber's discomfort with what the third phase of Markdown's life has become. He frames it as three stages: not popular enough, then popular in exactly the right places, then—where he thinks we are now—spread to places it shouldn't be.

His specific complaint: editors that hide the Markdown syntax in a "view mode," showing you rendered text until you click to edit and the asterisks reappear. This, to Gruber, inverts the whole point. Markdown was designed as an alternative to both raw HTML and broken WYSIWYG editors (where moving a text cursor into italicized text and trying to exit the formatting was a nightmare of invisible state). The legible syntax was the solution: *it's in italics* or it isn't. Delete the asterisk, italics gone. No ambiguity.

What some modern Markdown editors have built, he argues, is just a WYSIWYG editor with extra steps—one that requires you to know the Markdown syntax to input content, but then hides that syntax from view. It captures the complexity of both systems and the advantage of neither.

Dash's counter is worth hearing out, because it's not wrong: Markdown is, objectively, faster than clicking toolbar buttons. The argument that everyone should just learn it—like learning keyboard shortcuts for copy/paste—has real force. The philosophical disagreement here isn't resolvable; it maps onto a genuine tension in interface design between power and accessibility that isn't going away.

Why LLMs love it (and it's not mystical)

The AI chapter of the Markdown story is where things get strange in an interesting way. Gruber is candid that he didn't see this coming. But he's also clear that, once you understand what LLMs are actually doing, it's not surprising at all.

"LLMs consume text trying to match patterns the way humans do. And so the fact—going back to your question—that I tried to make my number one priority for Markdown was to make it readable... readable to someone who doesn't even know what Markdown is, is exactly how LLMs parse text."

There's a structural point here about why Markdown outperforms JSON as an output format for language models: JSON is punishingly unforgiving. One misplaced comma and the file breaks. Markdown is the opposite—forget to close an italics run and nothing collapses, the text is still perfectly readable. The same forgiveness that made it accessible to non-technical bloggers in 2004 makes it resilient to the small errors that LLMs occasionally produce.

Dash's suggestion that Sam Altman should send Gruber $100 million is a joke, but it gestures at something real: an enormous amount of the infrastructure around AI prompting and output—the .md files, the system prompts, the formatted responses—rests on a convention built by one person with no expectation of compensation and no mechanism for collecting any.

The convention vs. spec question

One of the more underappreciated parts of the conversation is Gruber's insistence that Markdown is a convention, not a specification. He's never updated it to accommodate all the flavors that emerged. GitHub Flavored Markdown, CommonMark, and dozens of other variants add features the canonical version doesn't have. He's fine with this.

"I've always been of the opinion, let a thousand Markdowns bloom—it's not a syntax or a language per se, but a convention for writing plain text... The thing I'm happiest about isn't that Markdown particularly is so popular. It's that the various hundred different ways of italicizing something in plain text—I had strong opinions about those since the early 90s—and I thought everybody should do it my way. And that's really what Markdown has done."

There's something almost Zen about this as a software philosophy: instead of defending a spec, just make the convention obvious enough that people converge on it naturally. The web itself works this way—browsers render HTML loosely, standards get ignored or selectively implemented, and yet somehow the thing runs. The correctness of the spec matters less than whether the convention matches how people actually think and write.

Anil Dash made the broader point that younger developers and creators may have absorbed the output of this era of individual-built formats without ever learning the story of how they got there. Someone with a Stanford CS degree, he argued, might use Markdown every day without knowing where it came from—and that gap in the history they were told should probably raise some questions about whose contributions the official story of the tech industry actually centers.

That's not a rhetorical flourish. The Markdown story is a concrete example of something that's easy to say abstractly: the infrastructure of the internet was built by individuals, not just companies, and the individuals often got the convention right precisely because they weren't building for scale—they were building for themselves and trusting others to find it useful too.

The question that lingers, given where Markdown is headed next, is whether that model of individual-made conventions that spread organically is still possible when the platforms that would adopt them are trillion-dollar companies deciding unilaterally what their models output by default.

By Yuki Okonkwo, AI & Machine Learning Correspondent, Buzzrag