Markdown Was Never Meant for This

In 2004, John Gruber and Aaron Swartz published a small Perl script that converted plain text into HTML. The design goal was modest: let writers publish to the web without learning angle brackets. The syntax formalised conventions that already existed in plain-text email. A hash for a heading. Asterisks for emphasis. Dashes for lists. Nothing clever. Nothing ambitious.

Twenty-two years later, Markdown is the default output format of every major large language model on Earth. It structures how developers document code, how researchers write papers, how teams build websites, and how millions of people organise their thinking. The 2025 Stack Overflow Developer Survey named it the most admired documentation tool for the third consecutive year.

Nobody planned this. And that is precisely what makes it interesting.

From bloggers to builders

Markdown's first decade was quiet. It lived in developer circles, used mainly by people who already knew HTML but preferred not to type it. GitHub changed everything by making Markdown the default for README files, which meant every open-source project on the planet suddenly had Markdown at its front door.

Then Reddit adopted a flavour. Stack Overflow used it for answers. Slack built a subset into its message composer. Notion made it a core input method. Each platform took what it needed and ignored the rest.

The first real shift came with static site generators. Jekyll, Hugo, Eleventy, Astro: all of them treat Markdown files as the primary content layer. Write your thoughts in plain text, commit them to a repository, and the build system produces a website. No database. No content management system. Just files.

The second shift was knowledge management. Obsidian and Roam Research repositioned Markdown not as a publishing format but as a long-term data format. Your notes are just .md files in a folder. You own them. You can move them. No vendor lock-in. Obsidian's plugin ecosystem now allows Markdown notes to trigger automation, run dynamic queries, generate AI-assisted content, and integrate with external services. A plain-text file doing things its creators never imagined.

The AI accident

The third shift is the one that should make us pay attention.

Large language models produce Markdown by default. Ask GPT-4 a question, and it answers with headings, bold text, bullet points, and code blocks, all in Markdown. Ask Claude, Gemini, or Llama, and you get the same. No one instructed these models to prefer Markdown. They absorbed the preference from their training data.

Think about where high-quality text lives on the internet. GitHub repositories. Stack Overflow answers. Developer documentation. Technical blogs. These are among the richest, most structured, most carefully written sources available for training. And they are overwhelmingly written in Markdown.

Anil Dash put it sharply in January 2026: "All of it, all of it, is controlled through Markdown files." He was talking about the AI toolchain, the prompts, the system instructions, the output formatting. Markdown is the interface layer between humans and language models.

The numbers back this up. Research has shown that GPT-4 achieves 81.2% accuracy on reasoning tasks when prompts are formatted in Markdown, compared to 73.9% with JSON formatting. Markdown is not just the output format. It is a better input format too.

This was not designed. It emerged. And emergent infrastructure is the hardest kind to replace.

So is it a programming language?

Here is where the conversation gets genuinely interesting, and where I think the provocative framing is worth taking seriously for a moment before we answer it.

The strict computer science answer is no. Markdown lacks the fundamental properties of a programming language: variables, control flow, loops, state. It describes appearance, not behaviour. It is a markup language, which is what the "ML" would stand for if anyone had bothered to put it in the name.

But the spectrum from markup to programming is not binary, and the boundaries are blurring.

MDX allows you to embed React components directly inside Markdown files. Your content file can now import JavaScript, render interactive components, and respond to user input. A blog post that executes code is not quite a static document any more.

Markdoc, which Stripe released as open source in May 2022, takes a different approach. It extends CommonMark with tags, annotations, variable interpolation, and conditional content. You can write {% if user.plan == "pro" %} inside your Markdown and render different content based on context. That is declarative logic. It is not Turing-complete, but neither is SQL, and nobody argues about whether SQL is a real language.

Consider what Obsidian's Dataview plugin does. You write a query in a code block inside a Markdown file, and it dynamically generates a table of results drawn from your other notes. The Markdown file has become a database interface.

None of these extensions are standard Markdown. But they illustrate a pattern: Markdown keeps absorbing capabilities from the programming world because it sits in the right place. It is the layer where human intent meets machine execution.

The fragmentation problem

If Markdown is becoming infrastructure, it has a serious structural weakness: there is no single Markdown.

GitHub-Flavoured Markdown supports tables and task lists. MultiMarkdown adds footnotes and metadata. CommonMark attempted to create a rigorous specification but not everyone adopted it. Obsidian has its own conventions for internal links and callouts. Every platform renders identical source text slightly differently.

This fragmentation is manageable when Markdown is just a formatting convenience. It becomes a real problem when Markdown is your content layer, your AI interface, and your knowledge store simultaneously.

The lesson here is one the technology world keeps relearning. Informal standards work beautifully at small scale. They fracture under the weight of widespread adoption. HTML went through this. CSS went through this. JavaScript went through this. Markdown is going through it now, but without the governance structures that eventually stabilised those other technologies.

CommonMark is the closest thing to a solution, but adoption is inconsistent. There is no W3C for Markdown, no formal standards body, no versioned specification that platforms commit to supporting. For a format this important, that is a gap worth worrying about.

Why this matters beyond developer circles

You might reasonably ask why any of this matters if you are not a developer. The answer is that Markdown has quietly become the substrate for how knowledge is stored, shared, and processed in the AI era.

If you use Notion, you are writing Markdown. If you prompt ChatGPT, you are reading Markdown. If you use any documentation tool at work, there is a good chance Markdown is somewhere in the stack. If your company adopts an AI assistant, the system prompt controlling its behaviour is almost certainly a Markdown file.

This has practical implications for ordinary decisions. Choosing a note-taking app that stores files as Markdown means you can switch tools without losing your work. Understanding basic Markdown formatting makes you better at communicating with AI models. Knowing that Markdown fragmentation exists helps you ask the right questions when choosing platforms.

There is also an ethical dimension worth naming. Markdown is plain text. It is open. It is not owned by anyone. You do not need a licence to write it or a subscription to read it. In a world where content is increasingly locked inside proprietary formats and walled platforms, the continued dominance of an open, human-readable format is worth appreciating and protecting.

The accidental backbone

The most important infrastructure is often the kind nobody set out to build. Markdown was a weekend project to make blogging easier. It became the interface layer for artificial intelligence because it was simple, readable, and everywhere.

That trajectory tells us something about how technology actually develops. The things that win are not always the most powerful or the most elegant. They are the things that are easy to start using, hard to break, and present in the right place when the next wave arrives.

Markdown was in the right place three times running. For static sites. For knowledge management. For AI. The question is not whether Markdown is a programming language. It plainly is not, at least not yet, though its extensions are creeping in that direction. The more useful question is whether we are paying enough attention to the quiet, unglamorous formats that hold everything together.

The answer, as usual, is probably not.