Markdown Cheat Sheet: Complete Reference for Developers

markdown cheatsheet documentation formatting github

Markdown is the standard format for README files, documentation, GitHub comments, and developer notes. This cheat sheet covers every syntax element — from the horizontal rule markdown separator to advanced tables, code blocks, and extended GitHub Flavored Markdown. Use it as a quick reference while writing docs, blog posts, or wiki pages.

Horizontal Rule Markdown and Basic Syntax

A horizontal rule in Markdown creates a visual divider between sections. It renders as an <hr> element in HTML. Three or more hyphens, asterisks, or underscores on a standalone line produce a horizontal rule.

SyntaxResultNotes
---Horizontal ruleThree hyphens (most common)
***Horizontal ruleThree asterisks
___Horizontal ruleThree underscores
- - -Horizontal ruleSpaced hyphens also valid
# Heading 1<h1>Top-level heading
## Heading 2<h2>Section heading
### Heading 3<h3>Sub-section heading
#### Heading 4<h4>Minor heading
# My Document Title

This section introduces the topic.

---

This section continues after a divider.

***

Another section separated by asterisks.

Important: A horizontal rule markdown separator must sit on its own line, surrounded by blank lines. Placing --- immediately after a paragraph (with no blank line) causes the paragraph to render as a Setext-style heading instead — a common gotcha. Always add a blank line above and below ---.

Headings also use # characters — one through six, matching <h1> through <h6>. Only one H1 should appear per document; most static site generators inject the page title as the H1 automatically.

Text Formatting

Bold, italic, strikethrough, and highlighting apply inline emphasis. Most flavors of Markdown support all four.

SyntaxOutputUse Case
**bold**boldStrong emphasis
__bold__boldAlternative syntax
*italic*italicSoft emphasis, titles
_italic_italicAlternative syntax
***bold italic***bold italicMaximum emphasis
~~strikethrough~~strikethroughDeleted content (GFM)
`inline code`inline codeFilenames, commands, values
> textblockquoteCallouts, warnings, quotes
**Bold text** is used for critical information or UI element names.
*Italic text* works for book titles, technical terms, or mild emphasis.
~~Strikethrough~~ indicates deprecated content or corrections.
`code spans` wrap filenames, function names, or short commands inline.

> **Note:** Always add blank lines around blockquotes for consistent
> rendering across parsers.

Nested emphasis works in CommonMark: ***bold and italic*** or **_bold and italic_**. Avoid mixing * and _ inside the same word — parser behavior varies.

Markdown links use the [anchor text](url) pattern. Images use the same pattern prefixed with !.

SyntaxUse Case
[text](url)Inline hyperlink
[text](url "title")Link with hover tooltip
[text][ref]Reference-style link
[ref]: url "title"Reference definition (anywhere in file)
![alt text](url)Inline image
![alt text][img-ref]Reference-style image
<https://url>Auto-link (bare URL)
<email@example.com>Auto-linked email address
Visit the [CommonMark specification](https://spec.commonmark.org/) for full grammar rules.

Reference-style links keep long paragraphs readable:

Read the [original Markdown syntax guide][md-daring] for historical context.

[md-daring]: https://daringfireball.net/projects/markdown/syntax "John Gruber's original spec"

![Project logo](/images/logo.png "DevNook")

Reference-style links define the URL once and reuse the label multiple times — useful in technical documentation with repeated external citations. Markdown link syntax is identical whether you’re writing for a static site generator or an API documentation tool. For more cheatsheet references, the Python String Methods Cheatsheet and JavaScript Array Cheatsheet use the same linking patterns throughout.

Lists and Task Checklists

Unordered lists use -, *, or +. Ordered lists use 1. — Markdown auto-increments the number, so using 1. for every item makes reordering painless. Nest lists by indenting child items two or four spaces.

SyntaxOutputNotes
- itemBullet pointMost common
* itemBullet pointAlternate
+ itemBullet pointLess common
1. itemOrdered listAuto-numbered
1) itemOrdered listAlternate (GFM)
- nestedIndented sub-item2 or 4 spaces
- [ ] taskUnchecked checkboxGitHub Flavored Markdown
- [x] doneChecked checkboxGitHub Flavored Markdown
## Installation

1. Clone the repository
2. Install dependencies
   - Run `npm install`
   - Set environment variables in `.env`
3. Start the development server with `npm run dev`

## Pre-release Checklist

- [x] All unit tests pass
- [x] CHANGELOG updated
- [ ] Version bumped in package.json
- [ ] Production build verified
- [ ] Deployment reviewed

Task lists (checkboxes) are a GitHub Flavored Markdown extension. They render as interactive checkboxes in GitHub issues and pull requests — a practical way to track work items inside a repository.

Code Blocks and Inline Code

Inline code uses a single backtick. For blocks, use triple backticks (fenced code blocks) with an optional language identifier for syntax highlighting.

SyntaxUse Case
`code`Inline snippet, filenames
```langFenced code block with highlighting
```Plain fenced block
4-space indentLegacy indented code block

Common language tags: bash, shell, python, javascript, typescript, go, rust, java, sql, json, yaml, html, css, markdown, diff, plaintext.

Use `npm install` to install packages.

```bash
# Install dependencies and start server
npm install
npm run dev
```

```python
def word_count(text: str) -> int:
    return len(text.split())

print(word_count("hello world"))  # 2
```

```diff
- const old_function = () => {};
+ const newFunction = () => {};
```

The diff language tag is useful in documentation to show before/after changes. Fenced code blocks render in every major Markdown parser: GitHub, GitLab, VS Code, Obsidian, Notion, and static site generators like Astro, Jekyll, and Hugo.

Tables and Structured Data

GitHub Flavored Markdown (GFM) tables use pipes | to delimit columns and a separator row (---) to define the header. Most modern Markdown parsers and documentation platforms support GFM tables.

Syntax ElementDescription
| Col | Col |Table row
|---|---|Separator row (required after header)
|:---|Left-aligned column
|---:|Right-aligned column
|:---:|Center-aligned column
| HTTP Status | Meaning          | When to Use                       |
|:-----------:|-----------------|-----------------------------------|
| `200`       | OK               | Successful GET, POST, PUT         |
| `201`       | Created          | Resource created via POST         |
| `400`       | Bad Request      | Invalid client input              |
| `401`       | Unauthorized     | Missing or invalid authentication |
| `404`       | Not Found        | Resource does not exist           |
| `500`       | Internal Error   | Unhandled server exception        |

Pipe characters inside table cells must be escaped as \|. Column widths in the source do not need to align — the parser handles rendering. For an in-depth reference on HTTP statuses themselves, see the HTTP Status Codes Guide.

For complex layouts with merged cells or nested content, fall back to raw HTML tables — Markdown parsers render inline HTML inside .md files.

Escaping and Special Characters

Some characters have special meaning in Markdown. Prefix them with a backslash \ to render them literally.

CharacterNameEscaped Form
\Backslash\\
`Backtick\`
*Asterisk\*
_Underscore\_
{ }Curly braces\{ \}
[ ]Square brackets\[ \]
( )Parentheses\( \)
#Hash\#
+ - . !Misc punctuation\+ \- \. \!
Use \*asterisks\* when you want literal asterisks, not italics.

Render a literal backtick: \`code\`

Show a bracket without creating a link: \[not a link\]

HTML entities also work inside Markdown: &amp;, &lt;, &gt;, &copy;, &nbsp;. This is useful when writing technical documentation that includes angle brackets or HTML-like content outside of fenced code blocks.

Conclusion

This Markdown cheat sheet covers the full syntax — from horizontal rule markdown separators and basic headings to tables, task lists, code blocks, and escape sequences. Keep it open while writing README files, wikis, or developer documentation. For the complete Markdown grammar, refer to the CommonMark specification.