Markdown Cheat Sheet: GitHub-Flavored Markdown Complete Reference

Markdown is everywhere — GitHub READMEs, pull request descriptions, documentation sites, and note-taking apps. GitHub-Flavored Markdown (GFM) extends the CommonMark spec with tables, task lists, strikethrough, and autolinks. This cheat sheet covers everything in one place.

Preview your Markdown live →

Headings

# H1 — Page title
## H2 — Section
### H3 — Subsection
#### H4
##### H5
###### H6

Use heading hierarchy to structure your document. H1 is typically the document title; use H2/H3 for sections.

Emphasis

Syntax	Result
*italic* or _italic_	italic
**bold** or __bold__	bold
***bold italic***	bold italic
~~strikethrough~~	strikethrough (GFM only)

Lists

Unordered

- Item one
- Item two
  - Nested item (2-space indent)
  - Another nested item
- Item three

Supports -, *, or + as list markers. Be consistent within a list.

Ordered

1. First step
2. Second step
   1. Sub-step
   2. Sub-step
3. Third step

The actual numbers don’t matter — Markdown renders them sequentially regardless.

Task Lists (GFM)

- [x] Set up repository
- [x] Write README
- [ ] Add CI configuration
- [ ] Publish first release

Renders as interactive checkboxes on GitHub. Use in issues, PRs, and project documentation.

Code

Inline code

Use backticks for inline code: `variable_name`, `npm install`, `const x = 1`

Fenced code blocks

```javascript
function greet(name) {
  return `Hello, ${name}!`;
}
```

Supported language identifiers: js, javascript, ts, typescript, python, py, bash, sh, go, rust, java, c, cpp, json, yaml, html, css, sql, diff, markdown, and many more.

Code without syntax highlighting

```
plain text block
no syntax highlighting
```

Links

[Link text](https://example.com)
[Link with title](https://example.com "Hover title")
[Reference-style link][ref-id]

[ref-id]: https://example.com

Autolinks (GFM)

GFM automatically converts bare URLs and email addresses:

https://github.com becomes a clickable link
[email protected] becomes a mailto link

Images

![Alt text](image.png)
![Alt text](image.png "Optional title")
![Reference style][img-ref]

[img-ref]: /path/to/image.png

For images with links:

[![Alt text](image.png)](https://example.com)

Tables (GFM)

| Column 1 | Column 2 | Column 3 |
|----------|----------|----------|
| Cell     | Cell     | Cell     |
| Cell     | Cell     | Cell     |

Column alignment

| Left     | Center   | Right    |
|:---------|:--------:|---------:|
| aligned  | centered | right    |

• :--- — left align (default)
• :---: — center align
• ---: — right align

Tables don’t need to be perfectly aligned — the pipes just need to be present.

Blockquotes

> This is a blockquote.
>
> It can span multiple paragraphs.

> Nested blockquote level 1
>> Nested blockquote level 2

Horizontal Rules

Any of these produce a horizontal rule:

---
***
___

Footnotes (GFM extended)

This claim needs a citation.[^1]

[^1]: Source: Some reliable reference, 2024.

HTML in Markdown

Raw HTML is supported in most Markdown renderers:

<details>
<summary>Click to expand</summary>

Hidden content here. Markdown works **inside** HTML blocks on GitHub.

</details>

This is commonly used for collapsible sections in GitHub READMEs.

Escaping Characters

Use a backslash to escape Markdown characters:

\*not italic\*
\`not code\`
\# not a heading

Escapable characters: \, `, *, _, {, }, [, ], (, ), #, +, -, ., !

GitHub-Specific Extensions

Mentions

@username — mentions a user
@org/team — mentions a team

Issue and PR references

#123          — links to issue or PR number 123
user/repo#123 — cross-repository reference
SHA           — links to a specific commit (7+ characters)

Emoji (GFM)

:rocket: :white_check_mark: :warning: :tada:

GitHub renders these from the emoji shortcode list. Common ones:

• :warning: — ⚠️
• :white_check_mark: — ✅
• :x: — ❌
• :rocket: — 🚀
• :memo: — 📝

CommonMark vs GFM

Feature	CommonMark	GFM
Paragraphs, headings, lists	✅	✅
Fenced code blocks	✅	✅
Hard line breaks	✅	✅
Tables	❌	✅
Task lists	❌	✅
Strikethrough	❌	✅
Autolinks	Partial	✅
Mentions / issue refs	❌	✅

If you’re writing for GitHub, use GFM freely. For maximum portability (static site generators, other tools), stick to CommonMark.

README Best Practices

A solid GitHub README typically includes:

1. Project title and one-line description
2. Badges — build status, version, license
3. Installation — code block with commands
4. Usage — short example with code
5. API reference — table or list of key options
6. Contributing — link to CONTRIBUTING.md
7. License — one line with license type

Preview Your Markdown

Writing Markdown without a live preview is error-prone — especially for tables and nested lists. Paste your content into the preview tool to check rendering before committing.

Try the live Markdown preview → — renders GitHub-Flavored Markdown in real time, no account required.