Markdown Emphasis
TL;DR
- Use
*text*or_text_for italic emphasis. - Use
**text**or__text__for bold, also called strong emphasis. - Nested emphasis is allowed, but delimiter rules are more exact than they look.
- Inline code, links, images, and HTML bind more tightly than emphasis, so they can prevent emphasis from forming.
What it is
Emphasis is inline syntax that adds stress or weight to words and phrases. In CommonMark, italic and bold are part of the core inline grammar, not an extension.
Why it matters
Emphasis improves scanning and meaning with very little syntax. It is one of the first features people reach for, so learning the exact rules early prevents a lot of "why did this not render?" moments later.
Syntax
*italic*
_italic_
**bold**
__bold__
**bold with _nested italic_**
Minimal example
Source
This is *important*.
This is **very important**.
What it does
The first sentence renders one emphasized word in italic. The second renders one emphasized phrase in bold.
More examples
Example 1: Nested emphasis
**This text is _extremely_ important.**
What it does
This renders bold text with one italic word nested inside it.
Example 2: Bold plus italic
***Everything here is emphasized.***
What it does
This renders text with both bold and italic styling.
Example 3: Emphasis does not override inline code
Use `git status` before you commit.
What it does
Inline code stays code. Markdown does not turn characters inside a code span into emphasis.
Common pitfalls
- Forgetting to close the delimiter
- Why it happens: the opening marker is easy to spot, the closing one is easy to miss
- Fix: check that every opening
*,_,**, or__has a matching closer
- Assuming underscores and asterisks always behave identically
- Why it happens: both can create emphasis, but delimiter parsing rules are context-sensitive
- Fix: when text behaves strangely, simplify the span or prefer asterisks in prose
- Expecting emphasis to form inside code, links, images, or raw HTML
- Why it happens: those inline constructs take precedence over emphasis parsing
- Fix: decide whether you want code, a link, an image label, or emphasis, then write the syntax for that construct directly
- Overusing emphasis
- Why it happens: once emphasis is easy, it is tempting to style too much
- Fix: use emphasis only for meaning, not as a substitute for structure
Portability and platform notes
- Italic and bold are core Markdown features in CommonMark.
- GitHub supports the same basic italic and bold syntax in both comment fields and
.mdfiles. - GitHub also supports strikethrough, plus subscript, superscript, and underline through separate syntax or HTML, but those are adjacent topics and should not be treated as part of portable core emphasis.
- If emphasis does not render as expected, test the exact snippet in your target renderer rather than assuming every Markdown implementation resolves ambiguity the same way.
FAQ
Should I use * or _ for italic?
Both are valid. Pick one style and stay consistent. When debugging tricky cases, asterisks are often easier to reason about in ordinary prose.
Can I mix bold and italic?
Yes. Nested emphasis is valid, and triple delimiters can also produce bold plus italic when written correctly.
Why did my text not render as bold?
The most common reasons are unmatched delimiters, surrounding punctuation or characters that change delimiter behavior, or syntax that is already inside code, a link, an image label, or HTML.
Practice
- Write one sentence with italic, one with bold, and one with bold containing a nested italic word.
- Take a sentence that failed to render earlier and simplify it until you can see exactly which delimiter caused the problem.
Related topics
- Strikethrough
- Inline code spans
- Escaping and literal characters
- Links