Somewhere in the last few years, markdown stopped being a niche format favored by developers and became the connective tissue of a much larger kind of work. SKILL.md, CLAUDE.md, README.md, system prompts, agent instructions, project briefs, knowledge-base entries: all markdown, all unremarkable. Nobody announced this shift. There was no launch event, no version 2.0, no marketing campaign explaining why a text format from 2004 had suddenly become essential. It just happened, and most people who use it daily have not really stopped to ask why.
When you start to ask, the answer is more interesting than it first appears.
The easy explanation is that AI made markdown popular. There is some truth to this. Large language models are trained heavily on text that lives on GitHub, on documentation sites, on Stack Overflow, on every README ever written. They produce markdown fluently because they have read more of it than almost any human ever could. When you ask Claude or another assistant to write you a structured document, what comes back is markdown by default, because that is the format these systems think in.
But the AI explanation is incomplete. Markdown did not become useful because AI started producing it. AI started producing it because markdown was already the format that solved a problem the world had not yet admitted it had. The interesting question is what that problem actually is, and why the answer turned out to be a small, unassuming format with a few asterisks and pound signs.
There is something worth thinking through in that question, because it touches on a larger pattern: what we lose when our tools insist on controlling us, and what we gain when we find ones that step out of the way.
The Long Road Back to Plain Text
Markdown was created by John Gruber in 2004 as a way to write for the web without having to type out HTML tags. For about a decade, it stayed in that lane. Bloggers used it. Some technical writers used it. Most of the world kept using Word, kept emailing .doc files, kept accepting that documents were binary objects you opened with specific applications.
Then GitHub happened, or more precisely, GitHub’s culture of README files happened. Every open-source project needed documentation, and every project’s documentation lived in a file called README.md at the root of the repository. By the mid-2010s, if you wrote software, you wrote markdown. The format spread sideways from there: into static site generators like Jekyll and Hugo, into note-taking apps like Bear and iA Writer, into knowledge-management tools like Obsidian and Notion. Each adoption was small. Together they formed a slow tide.
The arrival of capable AI assistants in the 2020s did not invent this trajectory. It accelerated it and made it visible to people who had never written a line of code. A graphic designer using Claude to draft a project plan now interacts with markdown without thinking about it. A marketing lead asking ChatGPT for a content brief receives markdown headings and bullet points and copies them into Notion, which also runs on markdown underneath. The format that lived in the developer world for a decade became, almost without anyone noticing, the default working surface for knowledge work in general.
It is worth noting that markdown is not alone in this resurgence. LaTeX has its devoted users in academia. AsciiDoc handles technical documentation that markdown finds awkward. Typst is a more recent entrant aiming at the same territory. The phenomenon is bigger than any single format. Plain text, as a category, is recovering ground it gave up to binary documents in the 1990s. Markdown happens to be the most visible flag in that recovery, because it is the simplest and the most accessible.
What this means is that markdown’s rise is not a story about a clever format winning. It is a story about a long-running mistake correcting itself.
The Sense of Emancipation
There is a feeling that comes with writing in markdown that does not show up in any feature comparison. It is hard to describe without sounding precious about it, but it is real, and it matters.
When I write in markdown, I am not interrupted. The asterisks for emphasis are part of the sentence, not a trip to a menu. The pound signs for headings sit at the start of a line and do their job. There is no toolbar suggesting I might want to change the font, no autocorrect rewriting my words, no ribbon at the top of the screen offering me forty-three things I do not need. The text moves at the speed I am thinking.
Compare this to writing in Word. Word is a capable tool, and for some kinds of work it remains the right choice. But Word treats formatting as a parallel system you toggle into and out of via clicks. Want bold? Stop typing, find the button, click it, turn it off when you are done. Want a heading? Choose from the styles menu. Want to indent a list? Hope the auto-indent guesses correctly, because if it does not, you will spend ten minutes fighting it. Word makes you switch modes; markdown lets you stay in one.
I think of this in the same family as a smaller habit I have, which is writing without auto-capitalization and without using the shift key. Capital letters at the start of sentences are a convention from a different era of writing, when readers needed visual cues to parse dense typeset prose. In a chat window, in casual notes, they are vestigial. The software insists on them anyway. Turning them off is a small thing, but the texture of writing changes. Nothing interrupts you to enforce someone else’s idea of correctness.
Markdown has the same quality at a larger scale. The format is structural rather than presentational. You declare what something is (a heading, a list, an emphasized word) rather than how it should look. That is closer to how meaning actually works in your head when you write. You are not thinking “make this 18-point bold with 12 points of space below.” You are thinking “this is the start of a new section.” Markdown lets you write that thought directly.
This is what I mean by emancipation, though the word is heavier than the feeling. The freedom is not from binary formats in the abstract. It is from modal interruption. The tool stops making you stop. After enough years of fighting Word’s auto-formatting and watching Excel mangle dates that looked like phone numbers, the absence of friction feels like something larger than convenience. It feels like the software finally got out of the way.
Why Markdown and AI Belong Together
If markdown’s appeal to humans is that it disappears, its appeal to machines is that it is already structured. These are not separate properties. They are two views of the same fact.
A Word document is legible to humans but opaque to machines. To extract anything useful from a .docx file, you need libraries that parse XML, handle styles, walk through document trees, and translate the result into something a program can work with. The format is built to be opened by Word and rendered by Word, not to be understood by anything else.
Code is the opposite. Python and JavaScript are perfectly legible to machines but require training and context for humans to read. A non-programmer cannot pick up a codebase and understand it the way they can pick up a novel.
Markdown sits in a strange middle zone. A human with no training can read a markdown document at full speed, because it is just text with a few light marks. A machine can parse it just as easily, because the marks are unambiguous and consistent. The format does not require a translation layer in either direction.
This is the same property that large language models have, in their own way. They occupy a space between human and machine that did not really exist before. They are systems, but they handle natural language natively. They do not require you to learn syntax or write structured queries; they understand prose. At the same time, they can produce outputs that downstream programs can use directly, because they are operating in formats that programs can also read.
Markdown and LLMs are compatible because they are doing the same thing at different layers. Both are media that refuse the choice between “for people” and “for systems.” Both let meaning flow in both directions without losing fidelity. When you write a SKILL.md file, you are writing instructions that a human teammate could read tomorrow and that an AI could execute today. When an AI produces a draft for you in markdown, it is producing something you can read directly and also something you can paste into a static site generator, a knowledge base, or a documentation tool, with no transformation required.
This is why the combination feels generative rather than merely convenient. You are not using two tools that happen to work together. You are using two instances of the same underlying shift: toward formats and interfaces that do not force you to pick a side.
From File-Sharing to Folder-Thinking
The practical consequences of this shift become clearest at the level of how you organize your work.
For non-technical users, the dominant pattern is still the file. You have a Word document. You email it to a colleague. They edit it and email it back. The filename grows:
- project-plan.docx
- project-plan-v2.docx
- project-plan-v2-jane-edits.docx
- project-plan-FINAL.docx
- project-plan-FINAL-revised.docx
- project-plan-FINAL-revised-actually-final.docx.
Anyone who has worked in an office knows this pattern, and most have lived it. The file is the unit of collaboration, and the file’s history exists only as a graveyard of half-remembered versions sitting in someone’s downloads folder.
Software developers solved this problem decades ago, but the solution required tools that non-developers could not use. Version control systems like Git assume your work lives in plain text files inside a folder, and they track changes at the line level across the entire folder. The folder, not the file, is the unit of work. You see who changed what, when, and why. You can revert. You can branch. You can merge. The mess of “v2_revised_FINAL” simply does not happen, because the system itself remembers.
Markdown lets non-developers borrow this entire workflow, because markdown files behave like the plain text files that Git was designed to handle. A project becomes a folder. Inside that folder, you might have an “assets” directory for images, a “drafts” directory for previous versions, a “notes” directory for comments and side material, and an “output” directory where you keep the .docx, .pdf, or .pptx files you generate for sharing with people who still need binary formats. The main folder carries the project name. Everything related to the project lives in one place. Sharing the project means sharing the folder, not a file ripped out of context.
This sounds like a small reorganization, but it changes the shape of work. When the folder is the unit, you stop optimizing for the moment of handoff and start optimizing for the life of the project. Drafts accumulate without cluttering anything. Comments and notes have a home. The final output is one artifact among many, generated when needed, regenerated when something upstream changes.
It is also worth saying what this approach gets you free from. PowerPoint pulls everyone into being an amateur designer, because slides reward visual polish and punish text. Excel becomes a database for organizations that have no database, with all the data-integrity problems that follow. Word makes the document a sealed object, editable only by people with the right software and willing to navigate its formatting quirks. None of these tools is bad in itself. The problem is that they have defined what office work is, and that definition has cost us a lot of time and a lot of clarity.
A folder full of markdown files, with binary outputs generated as needed, is not a perfect answer. But it is closer to what knowledge work actually looks like when you strip away the conventions imposed by the tools.
What Markdown Becomes Next
It is tempting to predict that markdown will evolve into something more powerful, the way most successful formats eventually do. I do not think this is what will happen, and I want to explain why.
Every attempt to extend markdown has produced fragmentation rather than evolution. CommonMark tried to standardize the variants and ended up as one more variant. GitHub Flavored Markdown added tables and task lists and became its own thing. MDX added React components and became a different thing again. Pandoc supports a dozen flavors and lets you pick. The pattern is consistent: when markdown adds enough features to satisfy power users, it stops being the format that makes markdown valuable, which is a format you can teach in five minutes and that renders correctly almost everywhere.
The likely future is that markdown stays essentially as it is, while a handful of conventions accrete around it without changing its character. Tables were not in the original markdown specification but are now expected. Frontmatter, the YAML metadata block at the top of a file, became standard via Jekyll and is now everywhere. Footnotes work in most serious tools. Wiki-style links in double brackets are spreading from Obsidian into other applications. Callouts and admonitions are converging on a shared syntax. None of these will feel like a “next generation” of markdown when they finally stabilize. They will just be there, the way tables are now, and the way fenced code blocks with language hints already are.
The more interesting question is what markdown’s role becomes, even if its syntax stays roughly fixed.
Right now, markdown is a source format. You write it, and it gets converted to HTML, PDF, or whatever else you need. The markdown is the canonical version, and other formats are renderings of it. But as more documents are produced collaboratively by humans and AI systems, the canonical form may shift to something more abstract: a structured representation of intent, claims, references, and revisions, with markdown as one rendering among several. Notion already works this way internally. Its underlying data model is not markdown, even though it exports to markdown. Other tools are converging on similar architectures.
If that direction wins, markdown stops being the source of truth and becomes the interchange format: the layer everyone agrees to read and write, even though the actual storage is richer. This is roughly what happened to plain text in email. SMTP still moves plain text around, but underneath, your email client is doing far more sophisticated things. Markdown could become the SMTP of documents. The format would not change much. Its role would shift from “where the document lives” to “how documents pass between systems and minds.”
There is one more possibility worth naming, which is that markdown might increasingly become invisible infrastructure that most people never see. As voice interfaces and conversational AI mature, end users may stop typing markdown directly. They will speak or chat, and the AI will produce structured output, and they will read it back as prose. The markdown layer will exist, but it will sit between machines, not between humans. This is a strange outcome to imagine, but it would make markdown the Unicode of documents: a foundational standard that everyone depends on and almost nobody thinks about.
I suspect some mix of these futures is what we will get. Markdown stays mostly itself. A few conventions become standard. Its role shifts from source to interchange to infrastructure, depending on the use case. The breakthrough is not in the format. It is in what the format makes possible.
The Medium of Collaboration
The deepest thing markdown has done is something that does not show up in any of the explanations I have offered so far.
For most of computing history, formats served either humans or machines. Word documents were for humans. JSON files were for machines. The two worlds talked to each other through translation layers, with all the loss and friction that translation involves. You wrote a document for people, and if a system needed to do something with it, you wrote a separate parser, or you exported to a different format, or you accepted that the machine would understand only fragments of what the human had written.
Markdown breaks this division. A markdown file is a document for people and a structured input for machines at the same time, with no translation in between. It is also, increasingly, a document that humans and machines write together. You draft a section, an AI rewrites it, you accept some changes and reject others, the AI suggests new structure, you adjust the headings. What emerges from this process was authored by a collaboration that did not exist a decade ago.
This is what makes markdown more interesting than its specification suggests. It is the first widely accessible medium for collaboration between humans and systems that think differently. You write a SKILL.md file today. An AI reads it tomorrow and follows its guidance. A colleague reviews it next week and updates a section. Another AI uses the updated version next month. The file is not a static document. It is a living agreement between participants whose ways of processing information have very little in common, but who can all read and write the same simple format.
No format before markdown has done this at scale. Code came close, but code excludes most people. Word documents come close in the other direction, but they exclude machines. Markdown happens to sit at the precise place where the exclusion stops being necessary.
What I take from all of this is that the rise of markdown is not really about markdown. It is about a change in what writing is for, and who writing is between. For a long time, writing was a thing humans did to communicate with other humans, with machines occasionally helping at the edges. We are moving into a period where writing is also how we communicate with systems that can understand us, and how those systems communicate back, and how all of us together produce something none of us could produce alone.
Markdown turns out to be the format that lets this happen without anyone having to learn anything new. It was sitting there since 2004, simple and unfashionable, waiting for the world to need exactly what it offered. The world finally does. The breakthrough already happened. We are just catching up to noticing it.
Image: A photo captured by the author
Tom’s Blog 