Emphasis

The Four Forms

Emphasis uses * or _ as a delimiter. One is italic, two is bold, three is both.

*italic* and _italic_
**bold** and __bold__
***bold italic*** and ___bold italic___
**bold with _nested italic_ inside**
*italic with **nested bold** inside*

The asterisk and underscore forms produce identical output. The asterisk form is the one to standardize on, because underscores break inside words and markdownlint defaults to asterisks.

Intra-Word Emphasis

This is the one real behavioral difference between the two delimiters, and the source of most surprise.

• * works inside a word. un*frigging*believable italicizes the middle.
• _ does not work inside a word in CommonMark or GFM. snake_case_name stays literal, which is exactly why the rule exists.

un*frigging*believable    -> the middle is italic
snake_case_variable       -> stays literal, no italics
some__thing__here         -> stays literal in CommonMark
a*b*c                     -> the b is italic

Older Markdown.pl and a few legacy parsers italicize inside snake_case, mangling identifiers in prose. If a file must survive an unknown renderer, wrap identifiers in backticks rather than trusting the rule.

Delimiter Rules

CommonMark decides whether a run of * or _ opens or closes emphasis using flanking rules. In practice:

• No whitespace directly inside the delimiters. * not italic * renders literally.
• Opening and closing counts must match. **bold* does not produce bold.
• Punctuation adjacent to a delimiter can flip whether it opens or closes.

*this works*
* this does not, whitespace after the opener *
**mismatched*
**this works too**
"*quoted italic*"        -> works, punctuation is fine outside

To emphasize something adjacent to punctuation where flanking fails, escape or reach for HTML:

\*a literal asterisk\*
<em>forced italic</em>

Strikethrough

Strikethrough is a GFM extension, not CommonMark. It works on GitHub, GitLab, Discord, Slack (with a single tilde), and most modern renderers, and does nothing in a strict CommonMark parser.

~~this text is struck through~~
~single tilde~ works on GitHub, not in the GFM spec
~~**struck and bold**~~

The GFM spec defines only the double-tilde form. GitHub also accepts a single tilde, so a file that relies on ~text~ breaks when moved to another GFM implementation. Always write two.

Literal Asterisks and Underscores

Backslash-escape the delimiter, or put the text in a code span.

\*not italic\*
\_not italic\_
2 \* 3 = 6
`*literal asterisk in code*`
a \*\* b

Inside a code span nothing is interpreted, so a code span is the safer choice for anything the reader is meant to copy.

Use the `*args` and `**kwargs` forms.

Written without backticks, **kwargs would begin a bold run and swallow the rest of the line up to the next **.

Highlight, Subscript, Superscript

None of these are CommonMark. Support is per renderer, so check before using them in shared docs.

H<sub>2</sub>O and x<sup>2</sup> work on GitHub.
==This highlight does not work on GitHub.==

For portable subscripts and superscripts, the HTML tags are the reliable answer, since GitHub allows sub, sup, and mark through its sanitizer.

Emphasis in Other Contexts

Emphasis is inline, so it works inside headings, list items, table cells, blockquotes, and link text. It does not work inside code spans or fenced code blocks, where the characters stay literal.

markdown

A bold word in a heading

• a list item with emphasis
• another with code and bold

a quote with bold text

**bold link text**

text **not bold, this is code**

One practical note: bold inside a heading is usually redundant, since headings are already visually heavy. Reserve emphasis for prose.