Markdown is deliberately lightweight, which means a handful of ordinary punctuation marks — *, _, #, ` — pull double duty as formatting syntax. Most of the time that's convenient, but occasionally you want those characters to appear as themselves: a literal asterisk in a footnote, a real backslash in a Windows path, or a # that isn't a heading. That's when you need to escape characters in Markdown, and the tool for the job is the markdown escape backslash (\).
This guide covers what escaping is, the complete list of escapable characters, when escaping is actually necessary (and when it isn't), how code blocks change the rules, HTML-entity alternatives, and the mistakes that trip people up. If you'd like to follow along by pasting examples into a live renderer, open the MD File Viewer editor in a tab.
What "escaping" means and how the backslash works
In Markdown, escaping means placing a backslash (\) immediately before a character that would otherwise be interpreted as syntax, so the parser treats it as literal text. The backslash itself is then consumed and does not appear in the rendered output.
Use \*single asterisks\* without triggering italics.Renders as: Use single asterisks without triggering italics.
A few rules govern the markdown escape backslash:
- The backslash must come immediately before the target character — no space in between.
- It only escapes the next single character, not a whole word.
- Inside most contexts (paragraphs, list items, blockquotes), the backslash works as expected.
- If you need a literal backslash with nothing to escape, write
\\— the first backslash escapes the second.
A Windows path looks like C:\\Users\\name\\Documents.That renders as: A Windows path looks like C:\Users\name\Documents.
The full list of escapable characters
Not every character can be escaped — only the punctuation that has syntactic meaning. The table below is the complete reference you can keep coming back to.
| Character | Escaped form | Typical use / why it matters |
|---|---|---|
\ |
\\ |
Literal backslash (Windows paths, regex) |
` |
\` |
Inline code marker you want to show literally |
* |
\* |
Asterisk that shouldn't trigger emphasis or a list bullet |
_ |
\_ |
Underscore in identifiers like my_variable outside code |
{ } |
\{ \} |
Curly braces that shouldn't trigger raw HTML/attribute syntax |
[ ] |
\[ \] |
Brackets you don't want parsed as a link |
( ) |
\( \) |
Parentheses that shouldn't pair with brackets as a link |
# |
\# |
Hash that isn't a heading (e.g. #1, a hashtag) |
+ |
\+ |
Plus at line start that shouldn't become a list item |
- |
\- |
Dash at line start that shouldn't become a list item |
. |
\. |
A numbered-list separator like 1. you want to show literally |
! |
\! |
Exclamation before [ that shouldn't start an image |
~ |
\~ |
Tilde you don't want parsed as strikethrough (~~) |
> |
\> |
Greater-than at line start that shouldn't become a blockquote |
| ` | ` | | |
Characters not on this list — letters, digits, spaces, @, /, :, =, and most others — don't need escaping because they carry no formatting meaning. Adding a backslash before them usually just shows the backslash.
When you actually need to escape characters in Markdown
A common mistake is over-escaping — sprinkling backslashes everywhere "just in case." In practice, the parser only treats a special character as syntax in specific contexts. You only need to escape characters in Markdown when the character is in a position where the parser would otherwise consume it.
Escaping is usually required when:
- A
*or_appears where emphasis could begin (next to a letter on both sides). - A
#,-,+, or>sits at the start of a line, where headings, lists, or blockquotes are detected. - A
[is followed later by a]and then a(URL), which looks like a link. - A
|appears inside a table cell. - A
`is paired with another to form an inline code span.
Escaping is not needed when:
- The character sits in the middle of a word with spaces around it (
a * bstays literal). - The character is already inside a code span or code block (more on that next).
- The line clearly can't form the relevant construct (e.g.
#mid-sentence is just text).
- This is a real list item.
\- This line starts with a literal dash.The first renders as a bullet; the second renders as plain text starting with -.
Outside code: emphasis and literal symbols
The most frequent real-world case is showing emphasis characters as text. To print *italic* without rendering it italic, escape both markers:
To make text italic, wrap it in \*single asterisks\*.
The variable \_count\_ is an integer.Escaping inside vs. outside code blocks
Code spans and fenced code blocks are the cleanest way to show special characters, because everything inside them is literal — no escaping needed. This is one of the biggest simplifications available to you, and it's covered in depth in our guide to Markdown code blocks.
Inline: use `my_function` and `a * b` freely.
```text
No escaping needed here: * _ # > | \` \\
Inside that fenced block, the `*`, `_`, `#`, `>`, `|`, and even the backticks render exactly as typed. The lesson: when you need to show a snippet of code, a regex, or a shell command, reach for a code span or block **before** you reach for backslashes. It's both safer and more readable.
The same applies when you want to demonstrate emphasis syntax itself:
```md
In Markdown, `_word_` makes *word* italic.Wrap the _word_ part in backticks and the backslash problem disappears. For the broader picture of all formatting shortcuts, see the Markdown cheat sheet.
HTML entities as an alternative to the backslash
Sometimes a backslash is awkward or doesn't render the way you want (some renderers are stricter than others). In those cases, HTML character entities are a reliable fallback because they're universally understood by browsers. This is especially handy for characters like < and >, which aren't on the standard escapable list but matter when you don't want HTML-like tags to be passed through.
| Entity | Renders as | Use case |
|---|---|---|
< |
< |
Show angle brackets without triggering HTML |
> |
> |
Same, for the closing bracket |
& |
& |
A literal ampersand (avoid accidental entities) |
|
(non-breaking space) | Prevent a line break between two words |
— |
— | An em dash |
Write <div> to start a block, and use AT&T as an example.Renders as: Write
Note that within a fenced code block, entities are not decoded — they show up literally as <. So entities are best used in normal prose, while code blocks remain the right tool for showing raw markup.
Common mistakes and pitfalls
Even experienced writers hit a few recurring traps with the markdown escape backslash. Here's what to watch for.
1. Escaping inside code spans. Because code content is literal, \* inside backticks renders as \* — backslash included. Drop the escape there.
2. Forgetting the second backslash. To show a single \, you must write \\. A lone \ followed by a non-special character usually appears verbatim, but relying on that is fragile across renderers.
3. Escaping characters that don't need it. Writing \- mid-sentence is pointless — a dash not at line start is already plain text. Over-escaping makes source ugly and harder to maintain.
4. Mismatched emphasis pairs. If you escape the opening * but not the closing one, you can accidentally create half an emphasis span. Escape both, or use a code span instead.
5. Pipes inside tables. A literal | in a table cell will break the column layout unless you write \|. This is one of the few places escaping is mandatory even in "normal" text.
| Operator | Meaning |
|----------|---------|
| \| | pipe |
| && | and |6. Renderer differences. Standard CommonMark and most GitHub-Flavored Markdown parsers honour the backslash escapes listed above, but a few extended characters (~, {, }) only matter under specific extensions like strikethrough or attributes. For the full GFM behaviour, see the GitHub-Flavored Markdown guide.
Frequently Asked Questions
Do I need to escape every special character?
No. Only escape a character when it sits in a position where Markdown would otherwise interpret it as syntax. A # mid-sentence, a * surrounded by spaces, or any character inside a code block needs no escaping at all. Over-escaping is a bigger problem than under-escaping.
How do I show a literal backslash?
Use two backslashes: \\. The first escapes the second, so a single \ appears in the output. This is essential for Windows paths (C:\\Users) and regex patterns (\\d+).
What's the difference between escaping and using a code block?
Escaping turns one character literal while keeping it in normal prose; a code block makes an entire span literal and styles it as code. For anything more than a single symbol — especially code, commands, or syntax demonstrations — a code span or fenced block is cleaner and more readable. Pair this with bold and italic formatting (see the bold and italic guide) to keep prose readable.
Are HTML entities better than backslash escapes?
They solve slightly different problems. Backslashes handle the Markdown-specific characters (*, _, #, and so on); HTML entities handle characters that matter to the browser (<, >, &). For showing literal <tag> text, use <tag>; for showing literal *asterisks*, use \*.
Escaping in Markdown is a small skill that pays off whenever your content is about Markdown, code, or any text full of symbols. Reach first for code blocks when you can, fall back to the markdown escape backslash for stray characters in prose, and reserve HTML entities for angle brackets and ampersands. Keep the character table above bookmarked, and you'll rarely be surprised by what your renderer does — try any example in the MD File Viewer editor to see it rendered instantly.
Try it in your browser
Open the homepage editor to view, edit, and export Markdown instantly — no install required.