Markdown flavors compared

A Markdown flavor is a specific dialect of Markdown with its own rules and features, built on top of John Gruber's original 2004 syntax. The five that matter most are CommonMark, GitHub Flavored Markdown (GFM), MultiMarkdown, Markdown Extra, and Pandoc. They agree on the basics such as headings, emphasis, and lists, but differ sharply on extended features like tables, footnotes, and math.

Markdown flavors syntax reference

Markdown flavors key facts

• There is no single official Markdown standard. The 2004 original was never formally specified, so flavors filled the gap.
• CommonMark is the closest thing to a standard core. Its current spec is version 0.31.2, dated January 2024, and GitHub Flavored Markdown is built on top of it.
• The core elements (headings, emphasis, lists, links, blockquotes, code) render the same across all five flavors.
• The differences are almost entirely in extended features: tables, footnotes, definition lists, math, subscript and superscript, and highlight.
• Tables are the single biggest divide: supported by GFM, MultiMarkdown, Markdown Extra, and Pandoc, but not by strict CommonMark.
• For the most portable output, write CommonMark plus GFM tables. When you control the renderer and need footnotes or math, use Pandoc or MultiMarkdown.

Choose a target flavor before choosing syntax

Start with CommonMark when a document must be portable. Add GFM features for GitHub READMEs, issues, and repositories. Choose Pandoc when the workflow needs academic citations, rich metadata, footnotes, or conversion to formats such as PDF and DOCX. Note-taking apps may add their own links, callouts, embeds, and highlight syntax.

Do not label every widely supported extension “standard Markdown.” State the target renderer and provide a fallback for important content. If one file must work in several places, keep the body close to CommonMark and isolate platform-only syntax. Use the compatibility table below as a starting point, then test the actual destination versions.

What a Markdown flavor is and why they exist

When John Gruber and Aaron Swartz released Markdown in 2004, the specification was a short document and a Perl script, and the last original release was Markdown 1.0.1 in December 2004. It covered headings, emphasis, lists, links, images, blockquotes, and code, but left many edge cases undefined. It also had no syntax for common needs like tables, footnotes, or math.

Two forces produced the flavors we have today:

• Ambiguity in the original spec. The 2004 syntax description did not say how to handle many real-world inputs, so every implementation resolved the gaps differently. The same source could render differently in two tools. CommonMark exists to fix this by defining behavior precisely.
• Missing features. Writers needed tables, footnotes, definition lists, and math. Different communities added these as extensions, producing MultiMarkdown, Markdown Extra, GFM, and Pandoc, each with its own syntax choices.

A flavor, then, is a named set of parsing rules plus a set of supported extensions. Understanding which flavor your target platform uses is the difference between Markdown that renders correctly and Markdown that shows raw symbols.

A short profile of each flavor

CommonMark

• Origin: Launched in 2014 by a group including John MacFarlane (author of Pandoc), Jeff Atwood, and others, as a response to years of inconsistent Markdown parsing.
• Maintainer: The CommonMark project, with a public specification and reference implementations. The current spec is version 0.31.2, dated January 2024.
• What it adds: Precision, not features. CommonMark defines exactly how the core elements parse, including tricky cases in lists, emphasis, and blockquotes. It deliberately leaves out tables, footnotes, and other extensions so the core stays small and unambiguous. It is the foundation that GFM and many modern renderers build on.

GitHub Flavored Markdown (GFM)

• Origin: GitHub's dialect, formalized as a spec in 2017 on top of CommonMark.
• Maintainer: GitHub. The formal GFM spec (v0.29-gfm) has not changed since April 2019, while GitHub keeps shipping renderer features outside the spec.
• What it adds: The formal spec adds five extensions to CommonMark: tables, task lists, strikethrough, extended autolinks (bare URLs become links), and a tag filter for unsafe HTML. Separately, GitHub's renderer also supports footnotes, math, Mermaid diagrams, emoji shortcodes, and alert blockquotes, but these are GitHub platform features, not part of the GFM specification.

MultiMarkdown

• Origin: Created by Fletcher Penney in 2005 to add features needed for academic and long-form writing.
• Maintainer: Fletcher Penney. The current major version is MultiMarkdown 6.
• What it adds: Tables, footnotes, citations, definition lists, math (LaTeX for MathJax), superscript and subscript, cross-references, image and link attributes, and document metadata. It can output HTML, LaTeX, and other formats, which shaped many of its design choices.

Markdown Extra

• Origin: Created by Michel Fortin as an extension of PHP Markdown, first released in 2004 to 2005.
• Maintainer: Michel Fortin, with widely used ports in Python (as part of Python-Markdown's extra) and other languages.
• What it adds: Tables, fenced code blocks, footnotes, definition lists, abbreviations, and special attributes on elements including custom heading IDs. It is common in PHP content systems and static site tooling. It does not add superscript, subscript, strikethrough, or math.

Pandoc

• Origin: Created by John MacFarlane, first released in 2006 as a universal document converter.
• Maintainer: John MacFarlane and contributors. Actively developed.
• What it adds: The broadest extension set of any flavor, delivered as toggleable extensions. It supports tables (several styles), footnotes, definition lists, superscript and subscript, strikethrough, math, YAML metadata blocks, citations, and much more. Because Pandoc converts to and from dozens of formats, its Markdown is the most feature-complete but also the most configurable.

Flavor differences

This is the canonical feature-support matrix for Markdown flavors. Each cell summarises the cited specification or maintainer documentation. Renderer versions and enabled extensions can change the result. Read the legend before the table.

Legend: Yes means supported with dedicated syntax. No means not supported by that flavor's syntax (you would fall back to raw HTML). Partial means supported with caveats explained in the notes. Verify means genuinely uncertain or implementation-dependent.

Notes on each row

• Tables. Not in CommonMark. GFM, MultiMarkdown, Markdown Extra, and Pandoc all support pipe tables, though header and alignment syntax differs slightly between them.
• Footnotes. Not in CommonMark. MultiMarkdown, Markdown Extra, and Pandoc support the [^id] reference style. On GFM, footnotes are a GitHub renderer feature, not part of the formal spec, so they render on GitHub but are not guaranteed by the GFM specification itself, hence Partial.
• Task lists. GFM, MultiMarkdown, and Pandoc support - [ ] and - [x]. Classic Markdown Extra does not define task list syntax.
• Strikethrough. GFM and MultiMarkdown use ~~text~~. Pandoc supports it through the strikeout extension. Classic Markdown Extra does not include strikethrough.
• Definition lists. MultiMarkdown, Markdown Extra, and Pandoc support the term-and-colon definition list syntax. CommonMark and GFM do not.
• Heading IDs. MultiMarkdown, Markdown Extra, and Pandoc allow custom IDs, usually with a {#id} attribute after the heading. GFM does not offer custom-ID syntax, but GitHub auto-generates anchor slugs from heading text, which is why it is Partial rather than Yes.
• Subscript and superscript. Only MultiMarkdown and Pandoc define shorthand (H~2~O, 2^10^). CommonMark, GFM, and Markdown Extra require raw HTML <sub> and <sup>.
• Highlight. The ==text== mark syntax is not in any of the four main flavors. Pandoc supports it only when the mark extension is enabled, so it is Partial for Pandoc and No elsewhere. Some editors like Obsidian add it separately.
• Autolinks. All flavors support angle-bracket autolinks such as <https://example.com>. CommonMark is Partial because it does not linkify bare URLs written without angle brackets. GFM adds extended autolinks that turn bare URLs into links. Pandoc offers bare-URL linking through the autolink_bare_uris extension.
• Fenced code blocks. Supported everywhere. CommonMark, GFM, MultiMarkdown, and Pandoc use backtick fences; Markdown Extra historically used tilde fences and also supports backticks in common implementations.
• Math. MultiMarkdown and Pandoc support LaTeX math natively. On GitHub, math is a renderer feature rather than a spec feature, so GFM is Partial. CommonMark and classic Markdown Extra do not define math.
• YAML front matter. Pandoc parses YAML metadata blocks natively. MultiMarkdown has its own metadata format and accepts --- delimiters for partial YAML compatibility, so it is Partial. CommonMark, GFM, and Markdown Extra do not parse front matter as part of their syntax; static site tools strip it before rendering.

The most consequential differences

Tables are the biggest fault line. They are the single most requested feature and the clearest divide. If you write a pipe table, it renders on GitHub, in MultiMarkdown, in Markdown Extra, and in Pandoc, but a strict CommonMark renderer shows the raw pipes and dashes. Because so much modern Markdown targets GitHub, many people assume tables are core Markdown. They are not.

Footnotes and definition lists split the "academic" flavors from the "platform" flavors. MultiMarkdown, Markdown Extra, and Pandoc grew up serving long-form and scholarly writing, so they all support footnotes and definition lists. CommonMark stays minimal, and GFM only gained footnotes as a GitHub renderer add-on.

Subscript, superscript, and highlight are the least portable features. Only MultiMarkdown and Pandoc handle sub and superscript shorthand, and highlight (==) is effectively Pandoc-with-an-extension or editor-specific. If portability matters, prefer raw HTML <sub>, <sup>, and <mark>, which pass through most renderers that allow inline HTML.

Math and diagrams are renderer territory, not spec territory. Even where a flavor "supports" math, actual rendering depends on a math engine like MathJax or KaTeX being wired into the renderer. GitHub, Pandoc, and MultiMarkdown each handle this differently, so the same $...$ block can render or not depending on the tool, independent of the flavor label.

GFM is a moving target defined by a frozen spec. The formal GFM spec has not changed since 2019, but GitHub's live renderer keeps adding features (alerts, math, Mermaid, emoji). When people say "GFM," they often mean "whatever GitHub renders today," which is a superset of the written spec. Keep that distinction in mind when you rely on a feature.

Other platforms (Slack, Discord, Reddit, Obsidian, Notion)

Chat and note tools each implement a partial, custom subset of Markdown, and these are the platforms Markdific's audience most often pastes AI-generated Markdown into:

• Slack: supports bold, italic, strikethrough, inline code, code blocks, and single-line blockquotes, but does not support headings, tables, or images by Markdown syntax. It uses *bold* (single asterisks) rather than the usual **bold**.
• Discord: supports bold, italic, strikethrough, spoilers, inline code, code blocks, and blockquotes, but not tables, headings by hash in older clients, or images. Newer clients added limited heading support.
• Reddit: uses a CommonMark-based renderer with tables, strikethrough, and superscript (^text), but requires strict spacing and a blank line before block elements.
• Obsidian: close to CommonMark and GFM, and additionally supports ==highlight==, LaTeX math, footnotes, and a rich callout system built on > [!type] syntax.
• Notion: supports headings (three levels), lists, quotes, code, and tables through its own block model, but ignores much raw Markdown when pasted and does not support footnotes or definition lists.

Choosing a Markdown flavor: a decision guide

You rarely pick a flavor in the abstract. In practice, the renderer picks it for you: whatever tool will display your Markdown determines which flavor's rules apply. Start there. The single most useful habit is to identify the target renderer first, then write for its flavor.

Match the flavor to what you are doing

Which flavor common platforms actually render

If you are not sure what a given tool uses, this lookup covers the common ones. When a tool is "based on" a flavor, it usually adds a few extras of its own.

When you control the renderer versus when you do not

The decision splits cleanly in two. When you control the renderer, such as your own site, a Pandoc pipeline, or a static-site generator, choose the most capable flavor that fits your stack, usually Pandoc for documents or GFM for developer content, and use its full feature set. When you do not control the renderer, such as content you paste into someone else's platform, write to the intersection of what your likely targets support rather than the union, and reach for raw HTML (<sub>, <sup>, <mark>) only where inline HTML is allowed.

When a document has to render in several places at once, target the smallest common feature set: CommonMark core, plus GFM tables, avoiding footnotes, definition lists, highlight, and subscript or superscript shorthand. That combination renders correctly in more places than any other.

How Markdific renders it

Markdific renders Markdown with a consistent feature set regardless of which flavor you authored in, so you can preview extended syntax in one place. Its confirmed capabilities include LaTeX math, Mermaid diagrams, fenced code blocks with syntax highlighting, and inline images.

For flavor-specific elements outside that confirmed set, such as footnotes, definition lists, and highlight, Markdific renders standard, portable output. Non-standard flavor syntax may appear as literal text unless the renderer supports it, so author portable syntax and preview it to see how it renders.

Because flavors disagree on output, the safest workflow is to author portable syntax and preview it before moving it to a target platform.

Try it in the Markdific online editor.

Common mistakes and gotchas

• Assuming tables are core Markdown. Tables are an extension. They fail in strict CommonMark renderers. Confirm your target supports them.
• Treating "GFM" as fixed. GitHub renders more than the frozen GFM spec defines. A feature that works on github.com may not work in another "GFM" library.
• Expecting footnotes everywhere. Footnotes are absent from CommonMark and are only a renderer add-on for GitHub. Use MultiMarkdown, Markdown Extra, or Pandoc when you need reliable footnotes.
• Using ==highlight== for portability. This works in almost none of the main flavors. Prefer <mark> if the renderer allows inline HTML.
• Relying on subscript and superscript shorthand. Only MultiMarkdown and Pandoc define it. Use <sub> and <sup> for portable documents.
• Copying front matter into a plain renderer. YAML front matter is parsed by Pandoc and by static site generators, not by CommonMark or GFM. In a plain renderer it can appear as a table or literal text.
• Mixing flavor-specific syntax in one document. If a file must render in several tools, target the intersection of their features, not the union.

Best practices

• Identify the target platform first, then write for that flavor's rules.
• For maximum portability, stick to the CommonMark core plus GFM tables, which the widest set of renderers understands.
• When you need footnotes, definition lists, or math and control the renderer, choose Pandoc or MultiMarkdown.
• Use raw HTML (<sub>, <sup>, <mark>, <abbr>) for features no flavor covers portably, and only where inline HTML is allowed.
• Preview extended syntax before publishing, since the same source can render differently across flavors.
• Document which flavor a project targets so contributors do not introduce syntax that silently breaks elsewhere.

HTML equivalent

Markdown flavors agree on the HTML for core elements but diverge on extended ones. The same source can compile to different HTML depending on the flavor, which is the practical reason the differences matter.

Markdown

~~struck~~ and a footnote.[^1]

[^1]: The note text.

HTML output (Pandoc or MultiMarkdown)

<p><del>struck</del> and a footnote.<a href="#fn1" class="footnote-ref" id="fnref1"><sup>1</sup></a></p>
<section class="footnotes">
  <ol>
    <li id="fn1"><p>The note text.</p></li>
  </ol>
</section>

HTML output (strict CommonMark)

<p>~~struck~~ and a footnote.[^1]</p>
<p>[^1]: The note text.</p>

In strict CommonMark the strikethrough and footnote syntax are not recognized, so the raw characters pass through as literal text. This is exactly why choosing the right flavor for the target renderer matters.

FAQ

What are the main Markdown flavors? The five most important are CommonMark, GitHub Flavored Markdown (GFM), MultiMarkdown, Markdown Extra, and Pandoc. CommonMark defines a strict core, and the others add extended features like tables, footnotes, and math.

Is Markdown the same everywhere? No. All flavors share the core syntax for headings, emphasis, lists, and links, but they differ on extended features. Tables, footnotes, definition lists, math, and highlight are supported by some flavors and not others.

What is the difference between CommonMark and GFM? CommonMark is a strict specification of core Markdown with no tables or task lists. GitHub Flavored Markdown builds on CommonMark and adds tables, task lists, strikethrough, and extended autolinks, plus extra GitHub renderer features like footnotes and math.

Which flavor supports tables? GFM, MultiMarkdown, Markdown Extra, and Pandoc all support pipe tables. CommonMark does not include tables, so a strict CommonMark renderer shows the raw pipe characters.

Which Markdown flavor should I use? Match the flavor to your platform. Use GFM for GitHub, Pandoc or MultiMarkdown for documents that need footnotes and math, and CommonMark plus GFM tables when you want the most portable output.

Do footnotes work in all Markdown flavors? No. Footnotes are absent from CommonMark. MultiMarkdown, Markdown Extra, and Pandoc support them with the reference-style syntax. GitHub renders footnotes, but they are a renderer feature rather than part of the formal GFM spec.

Why does my Markdown look different on GitHub than in another tool? Because GitHub's live renderer supports more than the frozen GFM specification, including alerts, math, and Mermaid. Another tool that claims GFM support may only implement the written spec, so those extras will not render.

How do I make Markdown that works everywhere? Stick to the CommonMark core, add GFM tables for the widest table support, and use raw HTML for features no flavor covers portably. Avoid highlight, subscript, and superscript shorthand in portable documents.

Is there an official Markdown standard? No single official standard exists. John Gruber's 2004 original was never formally specified, which is why flavors diverged. CommonMark is the closest thing to a standard, a precise specification that GitHub Flavored Markdown and many modern renderers build on.

Is CommonMark the same as standard Markdown? Almost. CommonMark is a strict, unambiguous specification of Gruber's original core. It does not add features like tables or footnotes, so it is best thought of as "standardized core Markdown" rather than a new flavor with extras.

What is the most widely used Markdown flavor? GitHub Flavored Markdown is the most widely encountered, because GitHub, GitLab, and many developer tools use it. It is a superset of CommonMark, which is itself the most widely implemented core specification.

What Markdown flavor do AI assistants like ChatGPT and Claude output? They generally produce GitHub-style Markdown built on CommonMark, using headings, emphasis, lists, fenced code blocks, and GFM tables. That is why pasting AI output into GitHub usually renders cleanly, while strict CommonMark renderers may not show the tables.

Sources and compatibility references

• CommonMark 0.31.2
• GitHub Flavored Markdown specification
• Pandoc User's Guide

Use these primary references for syntax rules. Renderer behaviour can still vary by version and configuration, so preview important documents in their final destination.

Related pages

• Markdown documentation hub
• Markdown cheat sheet
• Tables in Markdown
• Footnotes in Markdown
• Highlight text in Markdown
• Front matter in Markdown