GitHub Flavored Markdown (GFM): What It Is & What It Adds
What GFM adds to standard Markdown — and what it does not
What Is GitHub Flavored Markdown?
GitHub Flavored Markdown (GFM) is GitHub’s dialect of Markdown. It is a strict superset of CommonMark, the standardized version of Markdown, with extra features that software teams need every day: tables, task lists, strikethrough, autolinks, and syntax-highlighted code blocks.
GitHub publishes and maintains a formal GFM specification. Every valid CommonMark document is also valid GFM, so you never have to unlearn anything — GFM only adds. It is the flavor you are using whenever you write a README, an issue, a pull request description, a comment, a wiki page, or a Gist on GitHub.
This guide explains what GFM is and how it differs from standard Markdown. For the exact syntax of each feature, follow the “See full guide” links below.
GFM vs Standard Markdown (CommonMark)
CommonMark defines the core: headings, emphasis, links, images, lists, blockquotes, and code. GFM keeps all of that and layers on the features below.
| Feature | CommonMark | GFM | What it looks like |
|---|---|---|---|
| Tables | ❌ | ✅ | | a | b | pipe syntax |
| Task lists | ❌ | ✅ | - [ ] and - [x] |
| Strikethrough | ❌ | ✅ | ~~text~~ |
| Autolinks | ❌ | ✅ | Bare URLs and emails become links |
| Syntax highlighting | ❌ | ✅ | Colors code in fenced blocks by language |
| Emoji shortcodes | ❌ | ✅ | :rocket: renders as an emoji |
| Footnotes | ❌ | ✅ | Supported on GitHub since 2021 |
| Alerts / callouts | ❌ | ✅ | > [!NOTE] and four other types |
| Raw HTML | Passed through | Some tags filtered | GFM disables a short list of unsafe tags |
A note on precision: the formal GFM spec defines five extensions — tables, task lists, strikethrough, extended autolinks, and disallowed raw HTML. The rest (syntax highlighting, emoji, footnotes, alerts) are features of GitHub’s renderer that are widely considered part of “GitHub Flavored Markdown” in everyday use. CommonMark does let you tag a fenced block with a language, but it leaves coloring to the renderer.
Tables
Tables are the feature people miss most in plain Markdown. In GFM, pipes separate columns and a row of dashes marks the header, with colons controlling alignment.
| Feature | Status |
|---|---|
| Tables | Yes |
| Alerts | Yes |
| Feature | Status |
|---------|:------:|
| Tables | Yes |
| Alerts | Yes |Task Lists
Add [ ] or [x] after a list marker to get a checkbox. On GitHub, task lists in issues and pull requests are clickable and show progress in the issue list.
- Write the spec
- Review the draft
- Ship it
- [x] Write the spec
- [x] Review the draft
- [ ] Ship itStrikethrough
Wrap text in double tildes to cross it out. GFM also accepts single tildes on GitHub, but double tildes are the portable choice.
This is no longer true
~~This is no longer true~~Autolinks
In CommonMark you must wrap a URL in angle brackets or write full link syntax to make it clickable. GFM adds extended autolinks: URLs starting with http://, https://, or www., and plain email addresses, become links automatically. This is why pasting a link into a GitHub comment just works.
Docs: https://getmd.ma
Site: www.example.com
Mail: hello@example.com
Docs: https://getmd.ma
Site: www.example.com
Mail: hello@example.comGitHub also autolinks things that are not part of the spec at all, such as issue and PR references (#123), @username mentions, and commit SHAs. Those only work inside GitHub itself.
Syntax Highlighting
Put a language name right after the opening fence and GitHub colors the code for that language. It supports hundreds of languages, and an unknown or missing identifier simply renders as plain monospace text.
const greet = (name) => `Hello, ${name}!`;
console.log(greet("GFM"));```js
const greet = (name) => `Hello, ${name}!`;
console.log(greet("GFM"));
```Alerts and Callouts
GFM alerts (also called callouts or admonitions) turn a blockquote into a colored, labeled box. Start the blockquote with one of five markers. They are supported on GitHub in READMEs, issues, PRs, and wikis.
Note
Useful information that readers should know, even when skimming.
> [!NOTE]
> Useful information that readers should know, even when skimming.Tip
Optional advice to help readers do something better or faster.
> [!TIP]
> Optional advice to help readers do something better or faster.Important
Key information users need to succeed.
> [!IMPORTANT]
> Key information users need to succeed.Warning
Urgent info that needs immediate attention to avoid problems.
> [!WARNING]
> Urgent info that needs immediate attention to avoid problems.Caution
Advises about risks or negative outcomes of certain actions.
> [!CAUTION]
> Advises about risks or negative outcomes of certain actions.On platforms that do not support alerts, these simply render as ordinary blockquotes with [!NOTE] visible as text, so they degrade gracefully.
What GFM Does NOT Support
Many people expect features from word processors or other Markdown tools to work on GitHub. These do not, or only in limited form:
| Feature | On GitHub |
|---|---|
| Colored text | Not supported. Inline style attributes are stripped by GitHub’s sanitizer. See Markdown color for workarounds. |
| Underline | No Markdown syntax. See Markdown underline. |
Highlight ==text== | Not supported — shows as literal text. See Markdown highlight. |
| LaTeX math | Partial. Supported since 2022 with $...$ and $$...$$, but not every LaTeX command works. |
| Mermaid diagrams | Supported since 2022 — write a mermaid fenced code block and GitHub renders it as a diagram. Elsewhere it shows as a plain code block. See What is Mermaid? |
| Footnotes | Supported since 2021. See Markdown footnotes. |
Because GitHub sanitizes the HTML it renders, anything that depends on <style>, scripts, or inline styles will not survive. If your document needs those, preview it in a local tool rather than relying on GitHub.
Where GFM Works
On GitHub: README files, issues, pull requests, comments, discussions, wikis, and Gists all render GFM.
Beyond GitHub: many tools follow the GFM spec fully or in part.
| Tool | GFM support |
|---|---|
| VS Code | Markdown preview renders tables, task lists, and strikethrough |
| GitLab | Partial — GitLab Flavored Markdown is built on the same base with its own extras |
| Obsidian | Partial — tables, task lists, strikethrough, and callouts, with its own extensions |
| MDViewer | Renders GitHub Flavored Markdown, including interactive task lists |
Support details vary between tools and versions, so if a feature looks wrong in one app, check whether that app targets GFM or plain CommonMark.
FAQ
What is the difference between Markdown and GitHub Flavored Markdown?
Markdown is the original lightweight syntax for formatting text, standardized as CommonMark. GitHub Flavored Markdown is a superset of CommonMark that adds tables, task lists, strikethrough, autolinks, and (on GitHub) syntax highlighting, emoji shortcodes, footnotes, and alerts. Everything valid in standard Markdown also works in GFM.
Does GitLab use GitHub Flavored Markdown?
Not exactly. GitLab uses its own GitLab Flavored Markdown, which is built on CommonMark and supports many of the same features as GFM, such as tables, task lists, and strikethrough, plus its own extensions. Basic GFM documents usually render correctly on GitLab, but GitHub-specific features like alerts may differ.
Can I use GFM outside of GitHub?
Yes. GFM is an open specification, and many editors and viewers support it, including VS Code, Obsidian (partially), and MDViewer. Features defined in the spec, like tables, task lists, and strikethrough, are the most portable. GitHub-only features such as issue references and @mentions only work on GitHub.
Preview Your Markdown with MDViewer
MDViewer is a native macOS app for reading and previewing Markdown files. Double-click any .md file in Finder and see it rendered instantly — GitHub Flavored Markdown tables, task lists, code blocks, and more. Lite is free; Pro adds editing, Git history, and PDF export.
Requires macOS 13.0 or later. Intel and Apple Silicon.