Markdown Cheat Sheet: Syntax You'll Use Daily

Headings and Emphasis: The Daily Bread

Headings use hashes: one `#` for the biggest heading, `##` for the next level, down to six. In practice you'll use `#` once (the title) and `##` for sections — deeper levels are rare outside long documents. Put a space after the hashes (`## Section`, not `##Section`); without it, most renderers won't recognize the heading.

Emphasis is asterisks: wrap a word in single asterisks for italic (`italic`), double for bold (`bold`), triple for bold italic. Underscores work too (`_italic_`, `__bold__`), but asterisks are the more common convention — pick one and stay consistent within a document, because mixing them looks sloppy in the source.

Two emphasis-adjacent tricks worth knowing: `~~strikethrough~~` renders crossed-out text (handy in task lists and changelogs), and backticks make `inline code` — the single most-used Markdown feature among developers, for filenames, function names, and commands mentioned mid-sentence.

A horizontal rule — three or more dashes on their own line (`---`) — separates sections visually. Use it sparingly; if your document needs more than two or three, your headings probably need restructuring instead.

Links and Images Without the Fuss

Links are `[visible text](https://example.com)` — square brackets for what the reader sees, parentheses for where it goes. That's the whole syntax, and it covers 99% of linking. For a bare URL you want clickable, most modern renderers auto-link `https://example.com` without any markup, and angle brackets (`<https://example.com>`) force it in renderers that don't.

Reference-style links keep long documents readable: define `[label]: https://example.com/long/url` once (usually at the bottom), then write `[visible text][label]` wherever you need it. When the same URL appears five times or the URLs are paragraph-length tracking monstrosities, references keep your prose readable in the source.

Images are links with a bang: ``. The alt text matters — it's what screen readers announce and what displays if the image fails to load, so write something descriptive ("architecture diagram of the auth flow"), not "image" or the filename. You can also make an image clickable by wrapping it in a link: `[](https://example.com)`.

One gotcha: link destinations with parentheses inside them (looking at you, Wikipedia URLs) break the simple syntax — wrap the URL in angle brackets inside the parentheses and most renderers handle it.

Lists: Bullets, Numbers, and Checkboxes

Unordered lists use dashes (or asterisks, or plus signs — dashes are the most common convention): one `-` per item, each on its own line. Ordered lists use numbers followed by periods: `1.`, `2.`, `3.` — and here's the nice part, most renderers number them correctly even if you write `1.` for every item, so reordering items never means renumbering.

Nesting is indentation: indent a list item by two spaces (or a tab, depending on your renderer — two spaces is the safest) and it becomes a child of the item above. This is how you build hierarchies: a feature, its sub-requirements, their details. Inconsistent indentation is the number-one reason nested lists render wrong — when a sub-item pops out to the wrong level, count your spaces.

Task lists are GitHub-flavored Markdown's gift to productivity: `- [ ]` for an open item, `- [x]` for a done one. They render as clickable checkboxes in issues, PRs, and READMEs, and they've quietly replaced a thousand standalone todo apps for developers tracking work in context. Combine with strikethrough for the full task-tracking experience.

Tables: The One Syntax Everyone Googles

Nobody memorizes table syntax; everyone looks it up. Here it is, one more time, so this page can be the place you look it up: a header row with pipes between columns, a divider row of dashes (with optional colons for alignment), then your data rows. Like this in source: a line reading `| Name | Role |`, then `| --- | --- |`, then `| Dana | Engineer |`.

The divider row controls alignment: `|:---|` left-aligns, `|:---:|` centers, `|---:|` right-aligns. Column widths in the source don't matter — the renderer figures it out — so don't waste time aligning your pipes by hand (though many editors do it for you, and aligned source is easier to scan).

Tables are for genuinely tabular data: comparison matrices, config option references, schedules. They're not for layout — if you're reaching for a table to arrange a page visually, that's what CSS is for, and the table will be miserable to maintain. Also know the limits: no merged cells, no nested tables in standard Markdown. If your data needs those, it probably belongs in a real spreadsheet or an HTML table, not Markdown.

Code and Quotes: Developer Staples

Inline code — single backticks around `anything()` — is for mentioning code inside a sentence: function names, filenames, commands, config keys. It's the difference between "run the deploy script" and "run `deploy.sh`" — the second version is unambiguous about what's literal.

Code blocks are triple backticks on their own lines, with the language name right after the opening ticks for syntax highlighting. This is the single most important Markdown feature for developers: pasting code as a fenced block preserves indentation and (with the language tag) colors it readably. The language tag — `python`, `javascript`, `bash`, `sql` — costs four characters and transforms a gray wall into scannable code. Always include it.

Blockquotes use `>` at the start of the line, and they nest with `>>`. They're for quoting external text, callouts, and — in the style this very guide follows — highlighting key statements. A well-placed quote breaks up long prose and gives skimmers an anchor. Like horizontal rules, they're seasoning: effective in moderation, noise in excess.

Escaping: when you need a literal character that Markdown would otherwise interpret — an actual asterisk, a literal backtick — put a backslash before it (`\`, `` \` ``). You'll need this most often when writing about* Markdown syntax, which is delightfully meta and exactly as confusing as it sounds until you've done it twice.

A final workflow note: the fastest way to learn Markdown is the tight feedback loop of a live editor — type the syntax, watch the preview, correct what looks wrong. Reading a cheat sheet gives you the vocabulary; seeing your own `## Heading` turn into a real heading ten times is what moves it into muscle memory. Keep a scratch document open for a week, write everything in it in Markdown, and by day seven you won't be thinking about the syntax at all.