Markdown Cheat Sheet
The Markdown syntax developers actually use daily — headings, lists, links, tables, and code blocks — with real examples, common mistakes, and a searchable quick reference.
Headings & Emphasis
The syntax you'll use in the first line of nearly every Markdown file you ever write.
# Heading 1A # starts a heading — one # for the largest heading, up to six for the smallest (######). Most renderers require a space right after the #.
# Heading 1 ## Heading 2 ### Heading 3
**bold text**Wraps text in double asterisks (or double underscores) to make it bold.
*italic text*Wraps text in single asterisks (or single underscores) to italicize it.
***bold and italic***Triple asterisks combine bold and italic in one go — equivalent to wrapping *** around the text, or nesting ** inside *.
~~strikethrough~~Double tildes strike through text. A GitHub Flavored Markdown extension — see Task Lists & GFM Extras below.
Lists
Simple on the surface — the blank-line and indentation rules underneath are where almost every list-rendering surprise comes from.
- itemAn unordered list item. -, *, and + all work identically as the bullet marker — pick one and stay consistent within a document.
- First item - Second item - Third item
1. itemAn ordered list item. The actual numbers you type mostly don't matter — most renderers renumber sequentially starting from the first one, so 1. 1. 1. still renders as 1. 2. 3.
- nested itemNest a list by indenting it under a parent item. Indent consistently — commonly 2 or 4 spaces — matching where the parent item's own text starts.
- Parent item - Nested item - Another nested item - Back to top level
Links & Images
Four ways to point at something, each suited to a different situation.
[link text](https://example.com)The standard inline link — link text in square brackets, immediately followed by the URL in parentheses.
[link text](https://example.com "optional title")Add an optional title in quotes after the URL — shown by most browsers as a tooltip on hover.
Same syntax as a link, with a leading ! — the alt text is what shows if the image fails to load, and what screen readers announce.
[link text][ref]A reference-style link — the visible text stays inline, but the actual URL is defined elsewhere in the document, keyed by ref.
See the [documentation][docs] for details. [docs]: https://example.com/docs
<https://example.com>An autolink — angle brackets around a bare URL turn it into a clickable link without writing out the [text](url) form.
Code
Two forms: a short inline span, and a full fenced block for anything longer than a few words.
`inline code`Wraps a short code fragment in single backticks, rendered in monospace inline with the surrounding text.
```jsThree backticks open a fenced code block; the word right after the fence (js, python, bash) hints the renderer which language to syntax-highlight. Close the block with three backticks on their own line.
```js function hello() { console.log("hi"); } ```
Tables
A GitHub Flavored Markdown extension — not part of the original spec, but supported almost everywhere today.
| Header | Header |A table row — cells separated by pipe characters. The second row must be a --- separator with the same number of columns before any data rows are recognized as a table at all.
| Name | Role | | --- | --- | | Ada | Engineer | | Grace | Admiral |
:---:Colons in the separator row control column alignment: :--- left-aligns, :---: centers, and ---: right-aligns. Plain --- with no colons defaults to left.
Blockquotes & Horizontal Rules
Quoting other text, and visually separating sections.
> quoted textA > at the start of a line turns it into a blockquote, typically rendered indented with a vertical line down the left side.
>> nested quoteStack > characters to nest a blockquote inside another one — a blockquote can also contain other Markdown, including headings, lists, or code blocks, by continuing to prefix each of those lines with >.
---Three or more hyphens on their own line render a horizontal rule. *** and ___ work identically — pick one and stay consistent.
Task Lists & GFM Extras
GitHub Flavored Markdown extensions on top of the original spec — genuinely useful, but not guaranteed to render everywhere.
- [ ] todo itemAn unchecked task list checkbox. Space between the brackets — a literal, empty space character.
- [x] done itemA checked task list checkbox — lowercase or uppercase x both work. On GitHub, these render as real, clickable checkboxes in issues and pull requests, not just static ticks.
[^1]A footnote reference. Define its text elsewhere in the document with a matching [^1]: line — supported by GitHub and many extended renderers, not the original spec.
Here's a claim that needs a source.[^1] [^1]: The actual source, at the bottom of the document.
:smile:An emoji shortcode — supported by GitHub, GitLab, and some other renderers, entirely absent from the original Markdown spec.
Escaping & Raw HTML
Showing Markdown's own special characters literally, and dropping into HTML for anything Markdown itself can't express.
\*not italic\*A backslash immediately before a character that would otherwise trigger formatting escapes it, showing a literal asterisk instead of starting emphasis.
<div>raw html</div>Most Markdown renderers pass raw HTML straight through untouched, letting you drop into HTML for anything Markdown itself can't express.
<br>A raw HTML line break — a more visible alternative to the trailing-two-spaces convention covered in the next section.
<!-- comment -->An HTML comment — invisible in the rendered output. Some static site generators also repurpose this exact syntax for their own special directives.
Line Breaks & Front Matter
Two conventions that come up constantly in READMEs and static-site content, without being part of Markdown itself.
line one\Ending a line with a single backslash forces a line break within the same paragraph — visible and unambiguous in the source. The older convention, ending a line with two or more trailing spaces, works too, but is invisible in the source and gets silently trimmed by many editors on save, quietly breaking the line break.
---
title: My Post
date: 2026-07-08
---Front matter — a YAML block fenced by --- lines at the very top of a file, read as page metadata (title, date, tags) by static site generators like Jekyll, Hugo, Astro, and Eleventy, before the actual Markdown content begins. Not part of the Markdown spec itself — entirely a convention layered on top by these tools.
Quick Reference
Already comfortable with Markdown — just blanked on a syntax fragment? Search instead of scrolling.
# H1Largest heading, one # per level up to ######
###### H6Smallest heading level
**bold**Bold text
*italic*Italic text (or _italic_)
***bold italic***Bold and italic combined
~~strikethrough~~Strikethrough text
- itemUnordered list item (or * or +)
1. itemOrdered list item — numbers auto-renumber
- nestedNested list item, indented under its parent
[text](url)Inline link
[text][ref]Reference-style link, defined elsewhere in the file
Image
`code`Inline code span
```langFenced code block with a language hint
| col | col |Table row
:---:Center-align a table column
---:Right-align a table column
> quoteBlockquote
---Horizontal rule (or *** or ___)
- [ ] todoUnchecked task list item (GFM)
- [x] doneChecked task list item (GFM)
[^1]Footnote reference (GFM/extended)
:smile:Emoji shortcode (renderer-dependent)
\*Escape a character to show it literally
<!-- comment -->HTML comment, invisible in rendered output
25 of 25 commands
Common Use Cases
Real situations, not just isolated syntax — the exact combination that gets you through each one.
You need a README with headings, a code example, and a checklist
Combine three basics into one structured document:
- ## Section headings for structure
- Fenced ``` code blocks for install/usage examples
- - [ ] task list items for a roadmap section
You want a checklist your team can literally check off on GitHub
Task list syntax renders as clickable checkboxes in issues and PRs:
- - [ ] First task
- - [ ] Second task
Your table isn't rendering — it just shows pipes as plain text
Check the separator row's column count matches the header exactly:
- | Name | Role |
- | --- | --- |
You need to show Markdown syntax itself, without it being interpreted
Wrap it in a code span or fenced block instead of writing it as live text:
- `**not actually bold**`
You want one link reused in several places without repeating the URL
Define it once as a reference, cite it by label everywhere else:
- [the docs][docs] ... [again][docs]
- [docs]: https://example.com
You need to show a literal < or > without it being read as HTML
Escape it, or keep it inside a code span where Markdown doesn't parse it at all:
- `a < b`
Debugging & Troubleshooting
What actually shows up wrong on screen, decoded.
A list merged into the paragraph above it instead of rendering as a listAdd a blank line between the preceding paragraph and the list's first item. Many renderers require that separation to recognize the list as its own block at all.
A nested list turned into a new top-level list instead of nestingInconsistent indentation. Use the same number of spaces for every item at a given level — commonly 2 or 4 — and make sure it lines up with where the parent item's own text starts.
A table shows literal pipe characters instead of an actual tableCheck that every row — header, separator, and data rows alike — has the same number of | characters, and that a proper --- separator row sits directly under the header row.
Asterisks or underscores show up literally instead of becoming bold or italicEmphasis markers need to sit directly against the text they wrap, with no space in between. A stray space right after an opening * is a common reason it fails to trigger formatting.
A pasted URL didn't turn into a link, or rendered as a broken oneNot every renderer auto-links a bare URL with no special syntax at all. Wrap it in angle brackets for a guaranteed autolink, or use the full [text](url) form.
HTML tags you typed show up as visible text instead of being invisible or renderedFor an invisible comment, double-check you used the exact <!-- --> syntax. For HTML you actually want rendered, confirm the destination renderer allows raw HTML at all — many strip or escape it entirely for safety.
Things to Remember
If you forget everything else on this page, keep these.
- A blank line separates block elements (paragraphs, lists, headings) from each other — squeezing them together without one is the single most common rendering surprise.
- Fenced code blocks (triple backtick) beat indented ones — they support a language hint and don't require careful whitespace tracking.
- Reference-style links keep long URLs out of your prose and let you reuse the same link everywhere it's cited.
- Task lists, tables, strikethrough, and footnotes are GitHub Flavored Markdown extensions, not the original spec — they might not render everywhere.
- A table's separator row needs the same column count as its header row, or the whole table can fail to render.
- Raw HTML passes straight through most Markdown renderers untouched — powerful for your own content, a real risk if you're rendering someone else's unsanitized.
- Escape a character with a backslash to show it literally instead of triggering formatting.
- Indent nested content consistently — inconsistent spacing is the most common reason a nested list or blockquote breaks.
- Front matter (--- blocks of YAML at the top of a file) is a convention added by static site generators, not something Markdown itself defines.
Common Use Cases
About Markdown Cheat Sheet
Markdown looks trivial right up until a list refuses to nest, a table renders as a literal row of pipe characters, or a checkbox you swore worked on GitHub shows up as plain text somewhere else. Most cheat sheets show only the happy-path syntax and skip the handful of blank-line and whitespace rules that actually cause the confusing failures — the syntax itself was never the hard part.
This one starts with headings and text emphasis, into lists, links and images, code — both inline and fenced blocks — and tables. From there it covers blockquotes and horizontal rules, then GitHub Flavored Markdown's extras (task lists, footnotes, autolinks) that aren't part of the original spec and don't render everywhere, escaping and raw HTML, and the line-break and front-matter conventions that come up constantly in READMEs and static-site content without ever being part of Markdown itself.
Every section calls out the mistakes that actually break rendering: a missing blank line silently merging a list into the paragraph above it, inconsistent indentation turning a nested list into a second top-level one, a table's separator row with the wrong number of columns, GitHub-specific extras that quietly do nothing on a strict CommonMark renderer. There's a searchable quick reference for the moment you already know roughly what you want, and a troubleshooting section built around what actually shows up wrong on screen — literal pipe characters, a merged paragraph, a list that won't nest — not a paraphrase of it.
Like every tool on AllCoreKit, this page is fully static: the quick-reference search filters entirely in your browser, and nothing you read or search for is ever sent anywhere or logged.
Frequently Asked Questions
Related Tools
View all Cheat SheetsGit Cheat Sheet
The Git commands developers actually use daily, organized by workflow — branching, rebasing, undoing mistakes, and recovery — with real examples and a searchable quick reference.
Regex Cheat Sheet
The regex syntax developers actually reach for — anchors, character classes, groups, and lookaround — with real patterns, common mistakes, and a searchable quick reference.
Prompt Engineering Cheat Sheet
The prompt patterns that actually change LLM output — anatomy, few-shot, chain-of-thought, and structured formatting — with real examples, pitfalls, and a searchable quick reference.