Markdown Cheat Sheet: Everything You Need on One Page
I write everything in Markdown now — blog drafts, documentation, notes, even this site's content pipeline. The reason is simple: it's plain text, so it works everywhere and never locks you into an editor, but it converts cleanly into formatted HTML when you need it.
This cheat sheet covers the 90% of Markdown you'll actually use, with examples. Keep it bookmarked until the syntax becomes muscle memory (it takes about a week).
The basics: headings, emphasis, links
Headings use # symbols: # for H1, ## for H2, ### for H3. Bold is **text**, italic is *text*, and strikethrough is ~~text~~. Links are label and images are !alt — the same pattern with an exclamation mark.
These five cover most writing. I draft entire articles with just headings, bold, and links before touching anything fancier.
Lists, code, and quotes
- Unordered lists use - or * at the line start; nest with two-space indents.
- Ordered lists use 1. 2. 3. — the numbers auto-correct on render.
- Inline code uses `backticks`; code blocks use triple backticks with an optional language name.
- Blockquotes start lines with > — great for citing sources.
Horizontal rules are --- on their own line. I use them to separate major sections in long drafts.
Tables (and when to avoid them)
Tables use pipes and dashes: a header row, a separator row like |---|---|, then data rows. They render fine, but they're painful to edit by hand — I only use tables for genuinely tabular data (specs, comparisons) and reach for lists otherwise.
One more tip: different platforms support slightly different flavors (GitHub adds task lists and strikethrough; some CMSs don't). When in doubt, stick to the basics above — they work everywhere. And when you need HTML, paste your Markdown into our Markdown Converter for a clean, sanitized result.
Five Markdown mistakes that break your formatting
Most Markdown frustration comes from small, invisible rules. First, lists need a blank line before them — without it, the list often renders as plain text. Second, a heading needs a space after the # symbols: #Heading is not a heading, # Heading is. Third, to force a line break inside a paragraph you need two spaces at the end of the line or a blank line; a single Enter usually just wraps the text.
Fourth, special characters need escaping when you want them literally: write \* if you want an asterisk to show instead of starting emphasis, and \[ if you want a literal bracket. Fifth, code fences need to match — an unclosed triple-backtick block will swallow everything after it into one giant code block. When a document renders wrong, check these five first before blaming the tool.
A useful habit is to preview early and often. Draft in Markdown, convert a copy to HTML with our Markdown Converter to see exactly how it will render, and fix the syntax while the document is still short. Catching a broken table or list at 200 words is trivial; hunting for it at 2,000 words is not. And if you are polishing a finished draft, our Word Counter tells you at a glance whether you have hit your target length.
Task lists, footnotes, and other useful extras
GitHub-flavored Markdown adds task lists — - [ ] for an open item and - [x] for a done one — which render as checkboxes and are perfect for to-do lists inside a document. Footnotes work with a [^1] marker in the text and a [^1]: definition at the bottom, keeping long explanations out of the main flow. Both are widely supported, but neither is part of original Markdown, so check your platform before relying on them in a document that will be published elsewhere.
My rule for extras is simple: if the basics can say it, use the basics. Task lists and footnotes earn their place when they genuinely improve a document — a checklist, a sourced claim — not when they just show off syntax. A cheat sheet is most useful when it stays short enough to actually use, so I keep this one to the syntax that pays for itself every week.