The history of Markdown

In 2004, publishing text on the web meant one of two things: writing raw HTML by hand, or fighting a CMS editor that generated unpredictable markup behind the scenes. If you cared about both the writing and the output, neither option was satisfying.

John Gruber was writing long-form articles for his blog Daring Fireball and he wanted to think about words, not tags. Wrapping every paragraph in <p>, every emphasis in <em>, every code snippet in <pre><code> was not writing — it was transcription. And the source, when you opened the file, was unreadable.

His insight was that people had already solved this problem, quietly, in plain-text email. Since the 1980s, people had been writing *important*, _emphasis_, and - list items without thinking of it as markup — just as conventions that felt natural in a monospace font. Gruber formalised those conventions, added a Perl script that compiled them to HTML, and called the result Markdown.

The goal was never to replace HTML. Markdown was always a writing format, not a publishing format. The source file was for the writer; the output was for the browser. That distinction is what made it work.

Key moments

The people

Markdown has a small, identifiable cast. Understanding who they are explains most of why the format looks the way it does — and why it has never been standardised.

Anecdotes worth knowing

The name

Gruber named it Markdown as a deliberate play on HTML's "markup" — the idea being that Markdown is a layer down from markup: simpler, more readable, closer to how people write. The name also reflected his view that writing should feel lighter than coding.

The Perl script nobody was meant to maintain

The original implementation was a Perl script, Markdown.pl. Gruber wrote it for his own use and never intended it to become infrastructure. It was full of regular expressions, had no test suite, and was never designed to handle edge cases at scale. When developers started building platforms on it, the limitations became immediately obvious. The result was not a fork or a patch — it was a zoo of parallel implementations in every major language, each making slightly different choices.

The Standard Markdown incident

When Jeff Atwood announced the project in September 2014, he used the name Standard Markdown. Gruber's response on Twitter was swift and unambiguous: the name implied official status that Gruber had not endorsed, and he considered it a unilateral appropriation of something he had built. The team renamed the project to CommonMark within 72 hours. Gruber published a terse acknowledgement. Neither side ever fully reconciled publicly. The spec exists; Gruber's original description also still exists; they are not the same document.

Aaron Swartz's uncredited contribution

Swartz's role in creating Markdown was acknowledged informally — there are email threads, a page on his website — but the official Markdown documentation on Daring Fireball credits only Gruber. After Swartz's death, developers and writers revisited this. Gruber has described the collaboration as Swartz providing feedback, not co-authorship. Those who worked with Swartz during that period remember it differently. The historical record is incomplete.

The version that never came

Markdown 1.0 was released in December 2004. Markdown 1.0.1 followed in 2004 with minor fixes. Then nothing. For twenty years, Gruber has not released a new version of the original specification. He has said he considers it done. This is either an elegant statement about simplicity or the root cause of everything that followed, depending on who you ask.

Is there a central authority?

Strictly speaking: no. Markdown has no formal standards body, no ISO standard, no RFC. What exists instead is a hierarchy of influence.

The practical answer for anyone writing Markdown today: aim for CommonMark compatibility if you want maximum portability. Use GFM if you are writing for GitHub. Accept that the format you use on one platform may render slightly differently on another — and has done so since 2009.

How it spread — long before AI

Markdown's adoption in its first decade had nothing to do with artificial intelligence. It spread because it kept solving the same problem Gruber had — but for a steadily expanding group of people who needed to write structured text without becoming web developers.

Blogging and the early web (2004–2008)

The blogging era created a large audience of writers who were not programmers but who published online daily. Tools like Movable Type, WordPress, and Blosxom had built-in Markdown support relatively quickly. The format spread through the technical blogging community first — developers who ran their own sites and wanted to write in a text editor and paste into a CMS. Daring Fireball had a loyal readership that skewed exactly this way.

GitHub (2008)

GitHub launched in 2008 and made one consequential decision: README files should render as formatted text, not raw source. They chose Markdown. From that moment, every open-source project that put a README in its repository was publishing Markdown. Millions of developers encountered the format not as a deliberate choice but as the default way code was documented. The .md extension became synonymous with "documentation" in software projects worldwide.

Stack Overflow (2008)

Stack Overflow launched the same year as GitHub and also chose Markdown for question and answer formatting. Unlike a README that most people only read, Stack Overflow users wrote Markdown constantly — every question, every answer, every comment that needed a code block. This created a generation of developers who learned to write ``` before code and **bold** for emphasis without thinking about it.

Documentation tools (2010–2016)

Static site generators — Jekyll (2008), Hugo (2013), Gatsby (2015) — made Markdown the native format for building entire websites from plain-text files. Technical writers adopted it for software documentation. Sphinx, Read the Docs, and MkDocs made Markdown or reStructuredText the standard for open-source project documentation. By the mid-2010s, if you wrote technical documentation professionally, you almost certainly wrote Markdown.

Note-taking and knowledge tools (2013–2020)

A third wave came from note-taking software. Notion, Obsidian, Bear, Typora, and dozens of others used Markdown as their underlying format — sometimes exposed directly, sometimes hidden behind a visual editor. The appeal was the same as it had always been: files that could be opened in any text editor, searchable without a proprietary app, portable across tools. Markdown became the format of personal knowledge management.

Chat and communication (2015–2020)

Slack, Discord, and Microsoft Teams all adopted subsets of Markdown for message formatting. Suddenly people who had never thought about markup were typing *bold* and `code` in work chats. The format had escaped developer culture entirely. It was now a general-purpose tool for anyone who typed for a living.

By the time large language models arrived, Markdown was already the standard format for README files, developer documentation, and technical writing. The models did not create that status — they inherited it, trained on years of GitHub repositories and Stack Overflow answers, and amplified it into every chat interface on the internet.

Why it still matters

Markdown outlasted every trend it was adjacent to: the blogging era, the CMS wars, the static site generator wave, the note-taking app boom. It survived because it is not tied to any platform, any company, or any tool. A Markdown file from 2004 opens in any text editor today and looks exactly as it did then. That kind of durability is rare in software.

In the context of AI, Markdown has two advantages that Gruber never anticipated. The first is practical: it is token-efficient. HTML and most other structured formats are verbose — they wrap every piece of content in opening and closing tags, repeat attribute names, and add layers of nesting that exist for the parser, not the reader. A sentence in HTML can easily consume three times as many tokens as the same sentence in Markdown. For AI systems that charge by the token, or that work within fixed context windows, that overhead is not free. Markdown carries structure at low cost.

The second advantage is more fundamental: the same property that makes Markdown readable as plain text makes it natively legible to AI. A language model processes text. Markdown is text — structured, yes, but never opaque. A heading is a line that starts with #. A list is lines that start with -. The structure is in the characters, not in a binary format or a tag tree. Language models read and write Markdown fluently not just because they were trained on it, but because its design — readable source, no rendering required to understand it — is the design of a format that text-processing systems handle well. Gruber made that decision to serve writers. It turned out to serve machines too.

This is the idea behind plain text formatted (AI-ready) — taking Markdown's efficiency one step further for use in system prompts and instructions, where every token saved is a token available for meaning.

Today Markdown is also the default output format of most AI chat systems. Not because anyone designed it that way, but because large language models were trained on enormous amounts of it — years of README files, Stack Overflow answers, and documentation sites — and learned to write it naturally. A format invented to spare one blogger from writing HTML tags is now how AI communicates structure to humans.

Further reading: What is Markdown? · Which Markdown flavor for AI? · Plain text, formatted — what AI-ready really means