Inline Code
Inline code is the smallest code unit Markdown has: a pair of backticks around a few characters, and the renderer turns it into a run of monospace text. It is used almost exclusively to mark things the reader might need to type or recognize literally — a command, a file name, a variable, an environment variable, a key on the keyboard, an API route. Without the backticks, those words sit in the sentence looking like ordinary prose, and the reader cannot tell whether “npm install” is something to run or something being discussed.
The backticks do more than switch the font. Inside a code span, no Markdown is parsed at all: asterisks, underscores, brackets, and backslashes are all just characters that happen to be in the text. That is what makes inline code the safest way to display a fragment that looks like syntax, and it is also where most of the surprising edge cases live. This page walks through the exact rules — including what happens when the content itself contains a backtick, why the spaces at the ends of a span sometimes vanish, and why a backslash inside a code span does not escape anything.
One pair of backticks, used inline, is all it takes:
Run `npm install` to install the dependencies.
The variable `foo` holds the result.<p>Run <code>npm install</code> to install the dependencies.
The variable <code>foo</code> holds the result.</p>The rendered element is a plain <code> element. There is no <pre>, no line-break preservation, and no class attribute — inline code is a span of text inside a sentence, not a block of its own.
Nothing Inside Is Parsed
The single most useful property of a code span is that its contents are literal. Stars, underscores, brackets, and links all stop being syntax the moment they are between backticks:
Use `*asterisk*` and `**double stars**` to avoid emphasis.
Write `[not a link](https://example.com)` to show link syntax.<p>Use <code>*asterisk*</code> and <code>**double stars**</code> to avoid emphasis.
Write <code>[not a link](https://example.com)</code> to show link syntax.</p>This is how you write a tutorial about Markdown without accidentally writing Markdown, and it is why documentation about syntax always reaches for code spans. The same rule explains the precedence question: a code span wins over everything, because the parser resolves code spans before it looks for emphasis or links. *stars* inside backticks stays literal, and so does [**bold**](https://example.com) — the link is never formed. A code span may still sit inside link text, though: [a b c](https://example.com) produces a real link whose text contains a code span.
When the Content Contains a Backtick
If what you want to display already contains a backtick, you cannot wrap it in a single pair — the parser would pair your opening backtick with the one inside the content and stop early. The rule is simple: the outer run must be longer than any backtick run it contains. One backtick inside means two outside:
This is called `` `code` `` syntax.<p>This is called <code>`code`</code> syntax.</p>The same logic scales. A content run of two backticks needs three outside, and you are free to add more than the minimum whenever it helps you read the source:
```a ``b`` c```which renders as <code>a ``b`` c</code>. Adding a backtick is always safe, because the parser only cares that the closing run is at least as long as the innermost run it needs to skip over.
The Space-Trimming Rule
A code span whose content both starts and ends with a space loses one space at each end. The rule is specified this way so that you can write a span that contains nothing but a backtick:
`` ` `` means one backtick<p><code>`</code> means one backtick</p>Note that the inner backtick is not a run of three — it is a single backtick surrounded by spaces, so the outer pair of two backticks is enough. When only one side has a space, that space is kept exactly as written: ` a` renders as <code> a</code> and `a ` renders as <code>a </code>. Spaces in the middle are never touched, so `a b` keeps all four of them.
Backslashes Do Not Escape
Outside a code span, a backslash escapes the next character. Inside one, it is just a backslash, and the character after it is not escaped at all:
`a \* b` the star is not escaped<p><code>a \* b</code> the star is not escaped</p>For the same reason, the characters that would otherwise be HTML are escaped on the way out: <div> inside a code span is written as <div> in the generated HTML, and & becomes &. That is exactly the behavior you want — the fragment is displayed as text, never parsed as a tag.
The boundary of inline code is “short enough to sit inside a sentence”: one command, one path, one identifier, one config key. The classic cases are a shell command such as pnpm install, a file name such as README.md, a variable or environment variable such as NODE_ENV, an API route such as /api/users, and a keyboard shortcut such as Ctrl + S. In all of them the backticks carry a promise: this is literal, copy it as it is.
The reverse rule matters just as much. Anything the reader should not type verbatim should not be marked as code. Inline code has a strong “runnable” implication, so using it on an explanatory term makes readers pause and check whether they missed a step. If you want to stress a word, write it in italics or rephrase the sentence.
The trade-off is about scale, and it is worth deciding deliberately rather than by habit. A code block is a block-level element: it keeps its own line breaks, keeps its indentation, and can carry a language identifier for highlighting. An inline code span stays in the flow of the sentence, and it does not preserve line breaks — a newline inside one collapses into a single space, and a blank line ends the span altogether.
Use inline code when the fragment is a single token that fits naturally in the prose — pnpm install in the middle of a sentence. Use a code block when the content spans several lines, when indentation is meaningful, when the reader is expected to copy the whole thing, or when you want a language identifier to trigger highlighting. A whole command line that stands on its own is usually better as a one-line code block, because the block is visually distinct from the paragraph and can be given a bash identifier; a short command mentioned inside a sentence is better as inline code, because the sentence keeps its rhythm.
| Written as | What actually happens | Why |
|---|---|---|
npm install | Inline code | The basic form |
`code` | Inline code containing a backtick | The outer run must be longer than the inner one |
` | A single backtick | Spaces at both ends are trimmed, one at each end |
a | A leading space | Only one side had a space, so it is kept |
*stars* | *stars* | No emphasis is parsed inside a code span |
a \* b | a \* b | Backslashes do not escape inside a code span |
| A backtick pair spanning a blank line | Not code at all | A code span cannot cross a paragraph boundary |
A code span cannot cross a paragraph. A backtick pair may span a single line break — the newline collapses into a space — but the moment a blank line appears, the paragraph is over, the span ends, and the page shows the raw backticks and text instead of code. If a whole run of text shows up with stray backticks around it, look for a blank line inside what you thought was one span.
Rewrite the following sentence as Markdown. Requirements: mark the command, the file names, and the environment variable with inline code; and make the fragment that already contains backticks display literally, without being mistaken for the start of a code span.
First run pnpm install, then copy .env.example to .env.local; the `code` marker in README.md must stay as is, and finally set NODE_ENV to production.Approach:
Inline code uses a pair of backticks. The difficult part is the fragment that already contains backticks: wrapped in a single pair, the parser would pair the opening backtick with the one inside the content and the rest of the sentence would fall apart. The fix is to double the outer run, so the outer backticks are longer than the inner ones and the parser can find the real end.
Steps:
- Wrap the command
pnpm installin a single pair of backticks. - Wrap the two file names
.env.exampleand.env.localin separate pairs. They are two distinct paths, so they must not be merged into one span. - Wrap the environment variable
NODE_ENVin a single pair of backticks. - For the fragment that shows a backtick literally, use two backticks at the start and two at the end, keeping the original single backticks in the middle. The outer run is now longer than the inner one, so the span closes at the right place.
- Check the result: the command, both file names, and the environment variable render as monospace text, while the fragment renders as a backtick followed by
codeand another backtick — and the sentence is not cut in half.
Answer:
First run `pnpm install`, then copy `.env.example` to `.env.local`; the `` `code` `` marker in `README.md` must stay as is, and finally set `NODE_ENV` to `production`.You should now be able to write inline code correctly, to double the outer backticks when the content contains one, and to explain why the spaces at the ends of a span are trimmed, why backslashes do not escape, and why a span cannot cross a paragraph. You should also be able to say when inline code beats a code block and when it does not, and to notice at a glance that a run of text with stray backticks around it is a span that broke. From here on, every command, path, and identifier you type into a document can be wrapped in backticks without thinking about it — which is exactly how it should be.