An indented code block is a verbatim, monospaced block created by indenting every line of content by four spaces or one tab. It is the original code block syntax from the 2004 Markdown specification, predating fenced blocks.
Normal paragraph above.
This is an _indented_ code block.
**Every line** is indented by four spaces.
No Markdown processing occurs inside.
You can see that ** and _ have no effect,
the content is treated as plain text.
Normal paragraph below.
Normal paragraph above.
This is an _indented_ code block.
**Every line** is indented by four spaces.
No Markdown processing occurs inside.
You can see that ** and _ have no effect,
the content is treated as plain text.
Normal paragraph below.
Best Practice
- Prefer fenced code blocks (
```) over indented code blocks for all new writing. Fenced blocks support language tags, are easier to read in source, and work reliably inside list items. - Reserve indented code blocks for situations where your renderer does not support fenced blocks, or when maintaining legacy documents that already use this style.
- Never mix fenced and indented code block styles in the same document.
Notes
Historical Context
Indented code blocks were defined in John Gruber's original Markdown specification in 2004. At the time, no fenced syntax existed. The four-space rule was intuitive for authors who were accustomed to writing in plain text and indenting preformatted sections manually.
Fenced code blocks were introduced later — first by PHP Markdown Extra, then by other extensions — primarily to solve two problems with the indented form: the inability to specify a language, and the difficulty of using indented blocks inside list items.
Limitation Inside Lists
Indented code blocks do not work reliably inside list items. Because list item content is already indented, a code block inside a list item would require eight spaces of indentation (four for the list, four for the code), which most parsers do not handle consistently. Fenced code blocks are the correct choice in this context.
No Language Tag
Indented code blocks have no mechanism for specifying a language. Syntax highlighting is not possible without post-processing or renderer-specific conventions.
Markdown Flavour Support
Supported by all flavours as part of the original spec; largely superseded by fenced code blocks in modern use.
Flavour Support Detail
| Flavour | Support | Notes |
|---|---|---|
| Original Markdown | Yes | The original and only code block syntax in the 2004 spec. |
| CommonMark | Yes | Fully specified; fenced code blocks are preferred in practice. |
| GitHub Flavored Markdown | Yes | Supported but fenced blocks are recommended for language tagging. |
| Pandoc Markdown | Yes | Supported; Pandoc also supports an extended fenced syntax with attributes. |
Practical Examples
- Simple aligned table in a personal note: Four spaces of indentation creates a monospaced block, useful for keeping columns neat in a quick reference note when your editor does not support fenced blocks.
This month's scores:
Alice 98
Bob 85
Carol 91
This month's scores:
Alice 98
Bob 85
Carol 91
- Verbatim form layout in a lightweight editor: Simple note apps and older wikis support indented blocks for preserving exact spacing in a template or form.
Fill in the details below and send it back:
Name:
Date:
Preferred contact:
Fill in the details below and send it back:
Name:
Date:
Preferred contact:
- Preserving style in a legacy blog post: When editing an older post that already uses indented code blocks throughout, you can maintain the existing style without rewriting every block to fenced syntax.
The original post used the four-space style:
This text is displayed exactly as written,
with no Markdown processing applied.
The original post used the four-space style:
This text is displayed exactly as written,
with no Markdown processing applied.