Skip to main content
HomeBlogGitHub Flavored Markdown: Syntax, Extensions, and Preview Limits

GitHub Flavored Markdown: Syntax, Extensions, and Preview Limits

Use GFM tables, task lists, strikethrough, and autolinks, and distinguish the formal syntax from GitHub-specific rendering and security behavior.

Published:

Updated:

GitHub Flavored Markdown (GFM) builds on CommonMark with extensions used in repository documentation and discussions. Knowing the distinction helps when a file renders differently in a local editor, an online viewer, and GitHub.

The formal GFM specification covers syntax and HTML output. GitHub's website performs additional processing and sanitization, and has platform features beyond that specification. Supporting GFM does not promise an identical GitHub page.

Tables

A table needs a header, a delimiter row, and optional data rows:

| Task | Owner | Status |
| --- | --- | --- |
| Review source | Documentation team | Pending |
| Check export | Author | Complete |

Colons in the delimiter row specify alignment: :--- for left, :---: for center, and ---: for right. Escape a pipe inside a cell as \|. Blank lines around the table keep it separate from surrounding content and make the source easier to read.

A pipe table is not a layout system for merged cells or nested blocks. Keep complex layouts in a format that supports them. Use the table generator to build a grid or CSV to Markdown for existing delimited data.

Task lists

Put a checkbox marker at the beginning of a list item's text:

- [x] Read the document
- [ ] Check the links
- [ ] Open the exported file

The markers represent checked and unchecked states. A renderer may show disabled checkboxes; the GFM syntax itself does not make a document interactive or save a user's changes. Edit the source from [ ] to [x] when you need a portable record of completion.

Strikethrough

Use double tildes for a portable deletion marker:

Use ~~the legacy path~~ the current import route.

GitHub's formatting documentation also documents a single-tilde form. Renderer support differs, so prefer ~~text~~ when sharing the source between applications. A statement that single tildes never work would be inaccurate.

GFM can recognize bare URLs and email addresses:

Visit https://example.com/help or www.example.com.
Contact [email protected].

Autolinks do not run inside inline code or fenced code blocks. The URL in `https://example.com` is code text. For a document whose link labels matter, an explicit Markdown link such as [Help](https://example.com/help) is clearer and works without the autolink extension.

Fenced code and language hints

Fenced code blocks already belong to CommonMark. A language name is an information string that a hosting application can use for highlighting:

```js
const status = "reviewed";
console.log(status);
```

The parser identifies a code block; the application decides whether to highlight it and which language names it understands. Unsupported languages may remain readable plain code. A longer outer fence lets a tutorial display a shorter fence, as the example above demonstrates.

HTML filtering is a separate concern

GFM's disallowed-HTML extension filters a defined group of tags. It is not a complete application security sanitizer. GitHub adds further sanitization after converting Markdown to HTML.

MD File Viewer takes a different approach: it removes raw HTML from user input. An HTML <ins> underline or <br> line break that a publishing platform permits may therefore disappear in this preview. Use the underline guide and line-break guide to choose a supported alternative.

Do not assume that choosing a GFM parser alone makes arbitrary user content safe to publish. URL rules, allowed HTML, and embedding behavior also depend on the application.

What to preview at the destination

The MD viewer is useful for checking common GFM structure, supported math, and Mermaid diagrams. It does not reproduce GitHub's exact fonts, alerts, heading anchors, mentions, issue references, or every HTML choice. GitHub-specific alert markers can appear as ordinary blockquote text here.

Before publishing a README, check it in GitHub's own preview with the repository files available. Test relative image paths and links, because a standalone .md import cannot recreate the repository's directory structure. Before sharing an export, open that file too: HTML, Word, PDF, and image outputs have different capabilities.

For the underlying symbols, keep the Markdown cheat sheet nearby. Use a small representative example to test a renderer before moving a long document into it.

Try it in your browser

Open the homepage editor to view, edit, and download Markdown without installing an application.

More articles

GitHub Flavored Markdown: Syntax, Extensions, and Preview Limits | MD File Viewer