GitHub Flavored Markdown vs CommonMark: which one should your conversion target
Pick the wrong Markdown dialect for your destination and the conversion technically succeeds while the result quietly misrenders: tables turn into literal text, strikethrough shows its tildes, checkbox lists lose their boxes. The fix costs nothing, but only if you choose before converting.
This guide explains what CommonMark actually specifies, what GitHub Flavored Markdown adds on top, which platforms speak which flavor, and how the choice plays out in practice when a converter sits between your Word drafts and their final published destination.
CommonMark: one spec for core Markdown
Classic Markdown was a Perl script with a prose description, and by the 2010s dozens of implementations disagreed about basic cases: does a list continue after an indented paragraph, what counts as emphasis across line breaks, when is a number followed by a dot a list. The same file rendered differently almost everywhere.
CommonMark answered with a formal specification: an unambiguous grammar for Markdown's core syntax, hundreds of test examples with one correct rendering each, and reference implementations to check against. John MacFarlane, who also writes pandoc, was among its authors, and it took hold fast.
Today CommonMark is the base layer that nearly everything builds on. It deliberately does not include tables or strikethrough; it defines only the foundation those features sit on, which is exactly why a second layer of extensions was needed at all.
What GFM adds on top
GitHub Flavored Markdown, specified publicly in 2017, is a strict superset of CommonMark. Its additions are five: tables written with pipes, strikethrough with double tildes, task list items with checkboxes, automatic linking of bare URLs, and a filter that blocks certain raw HTML tags from executing.
Each addition targets something developers were already writing. Pipe tables cover dependency matrices and test matrices; task lists turn a README into a checklist; autolinks spare people from wrapping every URL in angle brackets. The HTML filter is a security measure, stripping the tags that make embedded HTML dangerous on a site where anyone can edit.
GitHub renders Markdown through cmark-gfm, a fork of the CommonMark reference implementation with these extensions wired in. GitLab and Gitea follow the same overall shape, which is why GFM behaves consistently across the major code forges rather than shifting from site to site.
Where each flavor lives
GFM is at home on GitHub, obviously, and on the static site tools that default to it: Hugo renders through an engine configured for GFM from the start, and MkDocs enables tables out of the box. Obsidian accepts all three signature constructs, pipe tables, strikethrough, and task lists, and adds its own dialect features on top.
Strict CommonMark parsers live in libraries and blog engines that deliberately favor a small, predictable core. Pandoc's own default Markdown is a third flavor altogether, a large superset with grid tables, citation syntax, and other extensions that GitHub will not render.
None of this makes one flavor better than the other. The question is never which dialect wins in the abstract, but which dialect your destination actually renders, and whether the file you are about to produce stays inside that boundary.
Why converters care about the difference
A converter does not just translate syntax, it chooses a dialect to emit. Tables are where the choice is most visible. If the target is GitHub and the output dialect supports pipe tables, a simple table arrives as a table. If the dialect does not, the same table can fall back to a syntax the destination ignores, and readers see rows of plain text with vertical bars in them.
Strikethrough and task list checkboxes fail the same way, only smaller: tildes left visible in the text, checkbox brackets that render literally. The document is not corrupted in any real sense, it is merely speaking a language the reader's renderer does not know.
This is also why the source format matters less than people expect. Pandoc parses the input, whether docx or CSV, into an abstract document model, and the dialect decision happens when writing the output. One reader, many writers, and the writer is what you control.
Choosing by destination
For anything that lands on a code forge or in a vault, choose GFM: GitHub pull requests, GitLab wikis, Obsidian notes, and Hugo sites all render its constructs. For a blog engine or library that advertises strict CommonMark, choose plain CommonMark and expect tables to need an HTML or extension fallback.
When you do not know the destination, GFM is the safer default. Its four visible additions are the most widely supported extensions in the Markdown world, and platforms that skip one of them usually degrade gracefully rather than showing raw syntax.
The one mistake worth avoiding is assuming a superset is always safe. A file written in pandoc Markdown with grid tables or citation syntax looks fine in pandoc and breaks on GitHub. Emitting the target's dialect beats emitting a richer one the target cannot parse.
What the GFM switch changes in conversion
The converter on this site exposes the choice as a single switch. With GFM enabled, Markdown output uses pipe tables, keeps strikethrough and task list syntax intact, and avoids constructs GitHub does not render, such as raw HTML image tags or width attributes attached to links.
Without it, output follows pandoc's own Markdown flavor: still perfectly valid, still readable, but complex tables can come out in dialects that GitHub ignores, and features beyond CommonMark's core are not guaranteed to land in their familiar GFM forms on the other side.
The switch also has one quiet interaction worth knowing: for CSV and TSV input, the result is a table document, and GFM mode is what keeps that table in the pipe syntax GitHub actually renders rather than a variant it ignores.
The line break edge case
Line breaks are the difference that survives every other choice. In CommonMark, a single newline inside a paragraph is a soft break, rendered as a space, and you need two trailing spaces or a backslash for a hard break. GFM keeps that rule for files.
Reality is messier: GitHub comments and issue bodies treat single newlines as visible breaks, and Obsidian does the same by default unless you enable strict line breaks in settings. So a paragraph wrapped mid-sentence renders one way on GitHub and another way in the README beside it.
The practical rule: write paragraphs as single long lines when the output is CommonMark or GFM, and only rely on newline-as-break where the platform has told you it works that way. Everything else about dialect choice is fixable after the fact; line breaks are the one that hides in plain sight.