Markdown flavors explained: CommonMark, GFM and the rest

There is no single Markdown. There is a 2004 description, a 2014 specification of its core, and a dozen sets of extensions bolted on by whoever needed tables, footnotes or maths. Which set a tool follows is its flavor, and it decides what your file looks like when it arrives. Below: what each flavor defines, and what four real renderers actually do with the same 36 pieces of Markdown.

What a flavor is

John Gruber's original Markdown was a description and a Perl script, and the description left a lot open: how deep a nested list indents, what a bare * means mid-word, whether a list can interrupt a paragraph. Every implementation that followed answered those questions its own way, then added the things the original lacked. A flavor is one implementation's set of answers plus its additions. The additions are the visible part; the answers are why two tools disagree about a document that uses nothing exotic at all.

The original, and the standard

CommonMark, published in 2014, is the attempt to pin the core down: a specification with over six hundred examples, each a required output for a given input. It defines headings, emphasis, lists, links, images, code, quotes, line breaks, escapes and raw HTML, and nothing else. Every renderer worth using follows it now, which is why the plain parts of a document look the same everywhere and the fancy parts do not. When a page on this site cites "the spec", this is the one.

GitHub Flavored Markdown

GFM is CommonMark plus five extensions: tables, task list items, strikethrough, autolinked bare URLs, and a filter that neutralises a short list of raw HTML tags. Its specification is the CommonMark text with those sections added, and because GitHub is where most Markdown is read, "supports GFM" became the thing other tools claim. Two things GitHub renders are not in GFM at all: footnotes and maths are GitHub features, which is why a file with either can look right on GitHub and wrong in a tool that faithfully implements the spec. GitLab's flavor is a further superset of its own, with diagrams and front matter among the additions. The GitHub Markdown page covers what the site itself does with a file.

The document flavors: MultiMarkdown, Markdown Extra, Pandoc

Three flavors grew from the same need: writing whole documents, not comments. Markdown Extra, from PHP, added tables, footnotes, definition lists, abbreviations and heading ids you write yourself. MultiMarkdown added most of that plus citations, cross-references, maths and a metadata block, aimed at people compiling to a finished file. Pandoc is the widest of all: its Markdown has an extension for nearly everything, each one switchable, and it is the converter of record when Markdown has to become LaTeX, Word or an ebook. The Markdown to LaTeX page is mostly about it.

What each flavor defines

Compiled from the specifications and manuals under Sources. A cell says what the flavor defines, which is not always what a platform renders: GitHub goes beyond GFM in two rows and is labelled as such.

What four renderers actually do

Specifications say what should happen. This table says what did. Each of the 36 constructs below was rendered by four libraries with their default settings, and the result was decided by inspecting the output for the element the construct is meant to produce: a <table> for a table, a <del> for strikethrough, and so on. Measured on 2026-09-13, with the versions in the header. Yes means the element appeared; No means the syntax came out as plain text, which is the correct behaviour for a flavor that does not define it.

Totals: marked 25 of 36, markdown-it 22 of 36, commonmark.js 21 of 36, micromark + GFM 26 of 36. Three things worth reading off it. The CommonMark reference implementation renders exactly the core and nothing more, which is its job. markdown-it escapes all raw HTML unless told otherwise, so its "Filtered" in the script row is a consequence of the "No" in the raw HTML row above it, not a GFM tag filter. And marked, which this site's editor is built on, passes a script tag straight through: that is why every document here goes through a sanitizer before it reaches the page, and why a renderer alone is never the whole of a safe Markdown tool.

The table is also a file: markdown-flavors.csv and markdown-flavors.json, with the samples, so anyone can re-run the same inputs. Free to reuse with a link back here.

Which flavor a platform uses

GitHub and GitLab speak GFM and their own extensions. Obsidian and most note apps take CommonMark and GFM and add wiki links and embeds of their own. Reddit's renderer descends from an older Markdown and adds superscript and spoilers. Chat apps, Slack, Discord, Teams and WhatsApp, implement a subset chosen for one-line messages, and two of them are not Markdown at all. The platform table has the element-by-element answer for each of them, and the examples page shows whole documents rendered as this site renders them.

Which one to write in

Write the core, and add GFM's tables and task lists when the destination understands them, which nearly every destination now does. Save the document flavors for documents that stay inside one tool: a definition list that renders in Pandoc is a colon on its own line everywhere else. If you need a file to survive a journey, the cheat sheet marks which elements are core and which are extensions, and the Markdown editor renders CommonMark and GFM, with footnotes, highlight and maths on top, so what you see here is close to the widest common ground.