In 2004, John Gruber released Markdown together with a Perl script, Markdown.pl, and a prose description of the syntax — but no formal grammar. For a decade, "what counts as valid Markdown" was effectively defined by what Gruber's own script happened to output, edge cases included.
Basic syntax
# Heading— headings at different levels based on the number of#characters.**bold**and*italic*— text emphasis.[text](url)— a link.- itemor1. item— bulleted and numbered lists.- ``` — code blocks with syntax highlighting by language name.
Why a "standard" took ten years to arrive
Because Gruber's spec was prose rather than a formal grammar, every implementation (PHP Markdown, Python-Markdown, Redcarpet, Pandoc) had to guess how to handle cases the original text left ambiguous: nested list indentation, emphasis next to punctuation, whether a list interrupts a paragraph. Different parsers guessed differently, and the same file could render differently depending on which one processed it. Babelmark, a tool that runs one input through dozens of parsers side by side, became the standard way to demonstrate just how much they disagreed.
CommonMark: writing down the actual rules
In 2014, a group that included Jeff Atwood (Stack Overflow, Discourse) and John MacFarlane (a philosophy professor and the author of Pandoc) started CommonMark: a fully specified grammar for Markdown, with a test suite of hundreds of cases and a reference implementation. It didn't replace Gruber's original — it formalized the 90% every implementation already agreed on and pinned down the 10% they didn't.
GFM: the extensions everyone actually uses
GitHub Flavored Markdown (GFM) builds on CommonMark and adds the features developers reach for constantly but that plain Markdown never defined: pipe tables, task lists (- [ ] / - [x]), strikethrough (~~text~~), and automatic linking of bare URLs. Because so much documentation lives in GitHub issues and READMEs, GFM has become the de facto baseline most tools — including this one — actually target, rather than Gruber's original 2004 rules.
Why you need this
- Quickly previewing how a Markdown file will render without publishing it.
- Converting a page or document's content to Markdown for storage in version control.
- Preparing HTML content for insertion into an app that only accepts Markdown.