CommonMark vs GitHub Flavored Markdown: What the Differences Actually Mean

CommonMark is the standardized, unambiguous specification for Markdown. GitHub Flavored Markdown (GFM) is a strict superset of CommonMark that adds a few practical features on top — tables, task lists, strikethrough, and automatic links — without changing the rules CommonMark already defines.

The short version

If you write plain CommonMark, your document renders the same way across any compliant tool. GFM keeps all of that and layers on extensions that GitHub needed for issues, pull requests, and READMEs. Everything valid in CommonMark is valid in GFM; the reverse isn't always true. A table or a task list written for GitHub may show up as raw text in a reader that only understands core CommonMark.

Here's the relationship at a glance:

| Question | CommonMark | GitHub Flavored Markdown | | --- | --- | --- | | Is it a formal spec? | Yes | Yes — built on CommonMark | | Tables | No | Yes | | Task lists | No | Yes | | Strikethrough | No | Yes | | Extended autolinks | No | Yes |

What CommonMark actually is

Markdown was created by John Gruber, with help from Aaron Swartz, in 2004 as a syntax description plus a Perl script called Markdown.pl. The original description was readable but didn't pin down every edge case, so different tools made different guesses. The same document could render one way in one app and differently in another.

CommonMark exists to fix that. It's a precise specification paired with a large suite of conformance tests, so any tool that claims CommonMark support behaves predictably. It stays faithful to Gruber's original syntax and only diverges to remove ambiguity. When people say "standard Markdown" today, CommonMark is usually what they mean, and the full grammar lives in the CommonMark spec.

CommonMark covers the constructs you reach for constantly: ATX headings (## Like this), emphasis, ordered and unordered lists, links and images, blockquotes, and fenced code blocks:

## A heading
Some **bold** text and a [link](https://example.com).

- a list item
- another item

What GFM adds on top

GitHub Flavored Markdown describes itself as a strict superset of CommonMark: every feature beyond the base spec is called an extension. There are a handful that matter day to day.

Tables. A header row, a delimiter row of dashes, then data rows:

| Name | Role |
| --- | --- |
| Ada | Author |

Task lists. Checkbox items inside a normal list, which GitHub renders as tickable boxes:

- [x] Write the draft
- [ ] Edit the draft

Strikethrough. Wrap text in double tildes to cross it out: ~~no longer true~~.

Extended autolinks. GFM turns a bare URL or www. address into a link without the explicit angle-bracket or []() syntax CommonMark requires.

GFM also defines a disallowed raw HTML rule that filters a small set of tags like <script> and <iframe> for safety. None of these break CommonMark — they sit alongside it.

When the difference matters (and when it doesn't)

For everyday writing, the difference is invisible. Headings, lists, links, emphasis, and code fences are core CommonMark, so they travel anywhere.

The difference shows up at the edges. If you rely on a GFM extension and then move the file to a tool that only speaks core CommonMark, the extension degrades. A task list becomes literal - [ ] text. A table prints as pipes and dashes. Strikethrough tildes show up verbatim. Nothing is lost from your file — the text is all still there — but the formatting doesn't render.

If you write across several tools, a portable plain-text habit pays off — see our other plain-text writing guides. A practical rule: write in core CommonMark when a document needs to stay portable across many tools, and reach for GFM extensions when you know the destination renders them, like a GitHub README or a tool built on the GFM spec. Because both are plain text, you can always check your raw file and see exactly what you wrote — there's no hidden formatting to untangle.

How Carets fits in

Knowing which flavor you're writing only helps if your editor keeps your text in plain, portable files. Carets does exactly that: it's a fast, native notes and code editor for iPhone, iPad, and Mac that stores your work as plain text — Markdown you can open in any other CommonMark or GFM tool, with nothing locked into a proprietary format.

Three things make it a good home for Markdown work. Its plain-text-first storage keeps your files future-proof and portable, so a document you write today opens cleanly years from now. Its syntax highlighting covers both your Markdown and any fenced code you drop in, which makes a GFM table or a task list easy to read while you edit. And files, projects, and tags keep a growing library of notes, READMEs, and snippets organized instead of scattered. For more on writing in plain text, browse the Carets articles.

Carets is available on the App Store for iPhone, iPad, and Mac.

Frequently Asked Questions

Is GFM the same as CommonMark?

No, but it's built on it. GFM is a strict superset of CommonMark — it includes everything CommonMark defines and adds extensions like tables, task lists, strikethrough, and extended autolinks.

Will a CommonMark document work on GitHub?

Yes. Because GFM is a superset, any valid CommonMark renders correctly on GitHub. The reverse isn't guaranteed: GFM-only features may not render in a tool that supports only core CommonMark.

Which one should I write in?

Write core CommonMark when portability matters most, since it renders consistently everywhere. Use GFM extensions when you know your destination supports them, such as a GitHub README.

Do my files change depending on the flavor?

No. Both are plain text, so the bytes you save are the same. Only the rendering differs — a GFM table either displays as a table or shows as plain pipes and dashes, but the underlying text is identical.