Why Markdown Won

Markdown was never the most capable markup format. HTML can express far more structure, LaTeX typesets far better, and formats like reStructuredText and AsciiDoc had tables and footnotes built in from the start. Markdown won anyway, and the reason is stated right in its original design goal: a Markdown document should be publishable as-is, as plain text, without looking like it's been marked up at all.

Readable before rendering

That goal drove every syntax decision. The conventions weren't invented — they were borrowed from how people already formatted plain-text email in the 1990s: *asterisks* for emphasis, dashes for lists, > for quoting a previous message, indentation for code. A reader who has never heard of Markdown can read a Markdown file and understand both the content and the structure. Compare that to the same document as HTML, where the signal is buried in angle brackets, or LaTeX, where a table is unreadable to anyone who doesn't know the format. Every other markup language asks the reader to tolerate the source; Markdown made the source the fallback presentation.

The lowest possible friction

The second thing Markdown got right is that the cost of formatting is nearly zero. There are no closing tags to balance, no schema to satisfy, and most syntax is a character or two you'd almost type anyway. Just as important, failure is graceful: mistype some Markdown and you get slightly wrong formatting inside a still-readable document. Mistype XML and the parser rejects the whole file. For quick notes, READMEs, and comments — the actual bulk of what people write — that asymmetry matters more than expressive power.

Plain text is what version control understands

Markdown's timing was lucky: it spread alongside git. Because Markdown is line-oriented plain text, diffs are meaningful — a one-sentence edit shows up as a one-line change that a human can review. Documentation can live in the same repository as code, go through the same pull requests, and merge with the same conflict resolution. A .docx file is a ZIP of XML that version control can only treat as an opaque blob; raw HTML diffs are technically possible but drowned in tag noise. Markdown made prose a first-class citizen of the code workflow, which is why every code host renders it natively.

The fragmentation problem

Markdown's weakness was that it launched as an implementation, not a specification. The original 2004 release was a Perl script, and its behavior was ambiguous in dozens of edge cases: how deeply indented a nested list must be, what emphasis does in the middle of a word, how blank lines interact with block quotes. Every re-implementation guessed differently, so the same document could render differently on different sites.

CommonMark (2014) fixed this by writing an exhaustive spec with hundreds of conformance examples, and most modern parsers follow it. On top of that sits GitHub Flavored Markdown (GFM), a set of CommonMark extensions that have become de facto standard: pipe tables, task lists (- [ ]), strikethrough, and autolinked URLs. When people say "Markdown" today they usually mean CommonMark plus some subset of GFM — and the remaining differences live in exactly those extensions, which is why tables that render on GitHub sometimes break elsewhere. A markdown viewer that follows GFM is the closest thing to a portable baseline.

Where it breaks down

The same minimalism that made Markdown win sets a hard ceiling. Pipe tables can't merge cells, span columns, or hold multi-line content — anything beyond a simple grid forces you into raw HTML. Footnotes, definition lists, and figure captions are extension-only, so they're exactly the features that break when a document moves between renderers. And the official escape hatch, inline HTML, quietly abandons the founding premise: a document full of <table> markup is no longer readable as plain text.

The practical rule: when a document is mostly structure — big tables, cross-references, precise layout — Markdown is the wrong tool. When it's mostly prose with light formatting, nothing beats it, and a markdown editor with live preview closes the remaining gap by showing you the rendered result while you type the plain text.

Markdown won for the same reason plain text keeps winning: the format that asks the least of both the writer and the reader is the one that ends up everywhere.