Fenced code blocks
Triple backticks open and close a code block, preserving whitespace and disabling normal Markdown formatting inside it — nothing between the fences gets interpreted as bold, links, or headings, it's rendered verbatim:
```
const x = 1;
```
The language identifier is what enables syntax highlighting
Adding a word immediately after the opening triple backticks tells the renderer which language's syntax rules to apply for highlighting:
```javascript
const x = 1;
```
Without it, most renderers fall back to plain, unhighlighted text — the code still displays correctly, just without color-coded keywords, strings, and comments. This identifier isn't part of core Markdown itself; it's a convention that renderers (GitHub, most static site generators, documentation tools) interpret, typically by handing the labeled content to a separate syntax-highlighting library.
The older, easy-to-forget alternative: indented code blocks
Before fenced code blocks were widely supported, Markdown's original syntax used 4-space (or 1-tab) indentation to denote a code block — no backticks involved:
const x = 1;
This still works in most parsers today, but it has real downsides fenced blocks fixed: no way to specify a language for highlighting, and it's easy to trigger accidentally (any paragraph indented 4 spaces becomes a code block, whether intended or not). Fenced blocks are the practical default now precisely because they're explicit and unambiguous about where the code starts and ends.
Inline code vs. block code
Single backticks (`like this`) mark short inline code within a sentence; triple backticks mark a standalone block. Mixing these up — using triple backticks for a single short term, or single backticks around multi-line content — produces unexpected formatting, since inline code doesn't preserve line breaks the way a fenced block does.
Common mistakes
- Forgetting the language identifier, losing syntax highlighting for no reason — always include it when the renderer supports it.
- Accidentally indenting a paragraph by 4 spaces, unintentionally triggering the older indented-code-block behavior in parsers that still support it.
- Using inline single backticks for multi-line code, which collapses line breaks — use a fenced block instead for anything spanning more than one line.
FAQ
Does the language identifier after triple backticks affect anything besides highlighting?
Generally no — it's purely a hint for syntax highlighting; the code's actual content and structure are unaffected regardless of what (or whether) a language is specified.
Is 4-space indentation still a valid way to create a code block?
In most parsers, yes, as a legacy behavior — but fenced code blocks (triple backticks) are the clearer, more explicit modern convention and avoid accidental triggering.
Can I nest a code block containing triple backticks inside another code block?
Yes — use four backticks (or more) for the outer fence, so the parser distinguishes it from the triple-backtick content inside.
Explore Markdown rendering behavior and structure with the Complete Guide to Markdown.