What’s covered
Every common Markdown syntax across eight sections. Click any “Copy” button to grab the example. Filter by typing a keyword (e.g., “table”, “list”, “link”) to narrow down.
The cheat sheet covers:
- Headings: both
#style and underline-style - Inline emphasis: bold, italic, strikethrough, inline code
- Lists: unordered, ordered, nested, task lists
- Links and images: including reference-style links and alt text
- Code blocks: fenced (with language), indented, inline
- Quotes and breaks: blockquotes, nesting, horizontal rules, line breaks
- Tables: basic syntax and column alignment (left / center / right)
- Footnotes & special: footnote references, raw HTML, escape sequences, emoji shortcodes
CommonMark vs GFM vs MDX
The Markdown universe has multiple dialects:
- CommonMark is the standardized core, what most parsers implement.
- GitHub Flavored Markdown (GFM) extends CommonMark with task lists, strikethrough, autolinks, and tables.
- MDX combines Markdown with JSX components for React-based content.
- Pandoc Markdown adds even more (definition lists, raw LaTeX, etc.) for academic writing.
This cheat sheet covers CommonMark + GFM. Most renderers (GitHub, GitLab, Reddit, Notion’s import, blogging platforms) understand this superset. The MDX-specific JSX bits and Pandoc-specific extensions are not included.
Things that look weird in raw Markdown
A few syntaxes catch people off guard:
- Two trailing spaces create a
<br>line break. Hard to see, easy to lose. If you want guaranteed line breaks without a paragraph break, use\at end of line in some flavors. - Empty lines matter. A list “broken” by a blank line followed by another item becomes two separate lists. Most renderers are lenient but consistent.
- Indented vs fenced code blocks. Indented (4 spaces) is older syntax; fenced (```) is what everyone uses now because it supports language hints.
- Tables need a header separator row. The
| --- | --- |row isn’t optional, it’s how the parser knows the previous row is the header.
Why use Markdown over HTML or rich text
Three reasons it’s stuck around for 20+ years:
- Plain text is durable. Markdown files are readable in any text editor, version-controllable in git, scriptable with grep/sed.
- Conversion is cheap. Markdown→HTML, Markdown→PDF, Markdown→slideshow all work with single CLI commands.
- Authoring stays focused. Without rich-text formatting buttons, you write content. Formatting comes later.
The trade-off: anything fancier than the listed syntax requires falling back to raw HTML inside the Markdown.
Frequently asked questions
Why doesn’t ~~strike~~ work everywhere?
Strikethrough is GFM, not core CommonMark. GitHub, GitLab, Reddit, Slack support it. Some older converters (Pandoc with default settings) don’t. If your renderer doesn’t support it, the source ~~text~~ shows up literally.
Can I use HTML tags inside Markdown?
Yes, most parsers pass HTML through. <kbd> for keyboard shortcuts, <sub> for subscripts, <details> for collapsible sections. Useful when Markdown’s vocabulary doesn’t cover what you need.
Why are tables so finicky?
The pipe character (|) inside cells needs escaping (\|) or it terminates the cell. Long content in cells doesn’t auto-wrap visually in most renderers. For complex tables, consider HTML or a dedicated table tool.
Where does the cheat sheet fall short? Footnotes have inconsistent renderer support. Definition lists aren’t covered (rare). The table syntax in this cheat sheet is GFM-flavored, Pandoc tables are different.