Syntax reference

Markdown syntax: the patterns you will use most

You can write useful Markdown with a small set of patterns. Start with semantic structure, leave blank lines around block elements, and preview the document in the renderer where it will be published.

8 minute read

Headings and paragraphs

Prefix a heading with one to six hash characters. Use one H1 for the document title, then descend through levels without choosing headings merely for their visual size. Paragraphs are separated by a blank line.

HeadingsMarkdown
# Document title

An opening paragraph.

## Installation

Setup details.

### Environment variables

Configuration details.

Emphasis, links, and images

Use asterisks for emphasis, square brackets for visible link text, and parentheses for the destination. Image syntax adds an exclamation mark; meaningful alternative text remains important when the image cannot be seen.

Inline syntaxMarkdown
Use **bold** for strong importance and *italic* for emphasis.

Read the [deployment guide](/guides/deploy).

![A diagram of the request flow](request-flow.png)

Lists and task lists

Start unordered items with a hyphen and ordered items with a number. Indent nested items consistently. Many developer platforms also support task-list checkboxes through GitHub Flavored Markdown.

ListsMarkdown
- Prepare the release
  - Update the changelog
  - Freeze migrations
- Deploy

1. Start the canary
2. Watch metrics
3. Expand traffic

- [x] Tests pass
- [ ] Docs reviewed

Inline code and fenced code blocks

Wrap short identifiers or commands in single backticks. Put longer examples between triple-backtick fences and add a language name when the renderer supports syntax highlighting. Keep executable examples complete enough to understand and test.

CodeMarkdown
Set `SERVICE_URL` in the server environment.

```ts
type Result = {
  markdown: string;
  fileName: string;
};
```

Blockquotes, rules, and tables

Blockquotes are useful for quoted material or short callouts. Horizontal rules separate major transitions. Tables work for compact, rectangular data; they become difficult to read when cells contain long prose or when the table is very wide.

GFM tableMarkdown
> Conversion preserves structure, not pixel-perfect layout.

---

| Format | Good for | Review |
| --- | --- | --- |
| DOCX | Styled prose | Tables |
| CSV | Small datasets | Escaping |

Write syntax that survives different renderers

Leave blank lines around headings, lists, tables, and fenced code blocks. Prefer descriptive links over bare URLs. Avoid raw HTML unless the publishing system explicitly supports and sanitizes it. When a feature is platform-specific, include enough plain text that the document still makes sense elsewhere.

A preview answers how the document renders here; your target repository or documentation system remains the final compatibility test.

Practice the syntax with live preview

Open a local draft and see headings, lists, code, and tables render as you type.

Try the editor