John Gruber (Markdown’s creator) has some thoughts on Markdown’s success:

[T]he biggest reason for Markdown’s continuing success isn’t Markdown itself. It’s the triumph of plain text files, both for system configuration and for the interchange of human-readable (and thus, LLM-readable) prose. Markdown isn’t really a “syntax”. It’s a set of conventions for formatting plain text. If everyone agrees to the same basic conventions, plain text can be significantly more expressive than a string of unformatted characters.

That’s it. So what I find gratifying isn’t that my “language” continues to thrive, because it’s not a language. It’s that the way I like to format plain text when I’m writing, and the way I like to see plain text formatted when I’m reading, has so thoroughly won the world’s mindshare battle. “Ha-ha”, I say, to people who want *this* to mean bold, not italic. (And to Slack and WhatsApp, I say “Fuck you.”)

— “Yours truly on the Vergecast: ‘# the **epic** story of Markdown’”, Daring Fireball, 2026-06-17.

And Gruber’s aspersions aside, it got me to thinking (again) about the sub-text-rapidly-becoming-text regarding readability above, if only because, while it is consistently part of Gruber’s design thinking regarding Markdown, it is just as consistently not paid anywhere near as much attention to by the folks who take the conventions he semi-formalised and run with them.

To quote from the 2004-12-17 article in which he introduced the project to the world:

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

Because Gruber’s overriding design goal is also one of Markdown’s core appeals to me, I’ve long been both aware of the tendency for others to cast said goal aside and frustrated that folks treat this goal as a flaw and a problem.

I like Markdown for multiple reasons, but two stand out.

First, it is a small enough set of conventions that incorporating it into my fingers was easy. I can write and markup text with high fluency because it’s all just typing and all the markup characters and consequent typing patterns are just as much a part of my muscle memory as the words are.

Especially since, as Gruber noted, Markdown is, to no small degree, the formalising of a set of conventions I already knew from years of writing plain-text emails (and UseNet posts, but the two existed as symbiotic and overlapping environments back in the day).¹

And, second, a Markdown–marked-up manuscript (so to speak) is as easy to read as a not-marked-up manuscript.

Easier, in fact, because, for example, *this* reads as emphasis more effectively to my brain than alternatives such as ‘this’ or _this_ or THIS. This is even more emphatically true thanks to pretty much every text editing environment I use offering syntax highlighting support for Markdown these days.²

To a non-trivial extent, the fact that I can run Gruber’s Perl script over a Markdown marked-up text file and have it spit out valid XHTML is a bonus. Even if all I got from Markdown was clearly structured but still easy-to-read-in-the-original-form plain text files, I’d still be a Markdown fan.

All of which is a long-winded way of re-iterating something I’ve long argued: Markdown is a set of formalised conventions designed for and in service to writers.

That it also has utility for publishers is great, but it is not the syntax’s central point nor is it the central goal.

And folks who get cranky at Markdown for not being more publisher-friendly are missing pretty much the whole point of Gruber’s project.

Which is not to say every extension to Markdown is wrong or wrong-headed.

For example, the widely-used tables markup syntax — formalised in GitHub Flavoured Markdown but extant and in wide use years before such formalisation — suits my presentation preferences for text files almost perfectly. And it is a small frustration that Gruber has never moved to incorporate this particular syntax extension into his own Perl script.

But it is to say that, to the extent any given extension to Gruber’s original set of formalised conventions doesn’t foreground the creation of easy to read in their original form text files, that extension is, I believe, mis-understanding Gruber’s design principles and goals.

Also, such extensions are mostly re-inventing the wheel anyway. If you need or want publisher-friendly or publishing-workflow–friendly plain text files, and don’t particularly care about how presentable the underlying plain-text files are, there is always AsciiDoc.

 

 

 

1. Also, and FWIW, I still use a text-only e-mail client to this day.

2. Syntax highlighting, in general, is so baked into the plain-text-reading-and-writing experience these days that when I, for example, need to fire up vi on a client machine, I am genuinely surprised if it turns out they haven’t set syntax on in their ~/.vimrc file.