Bold with two asterisks
Wrap text in two asterisks or two underscores and it renders bold:
The build is **already running** on staging.
The build is __already running__ on staging.**bold**and*italic*are the two forms worth using, because the underscore versions cause more trouble than they save.- A space just inside a marker kills it, so
** bold **prints the asterisks. - Underscores cannot emphasise inside a word, which is exactly what keeps
snake_caseintact. - Chinese bold fails when full-width punctuation sits inside the markers, and moving the punctuation out fixes it.
Both lines produce the same HTML, and it is <strong> rather than <b>. That matters. <strong> means strong importance, so a screen reader can treat it as content rather than decoration, and CSS supplies the weight.
If you only want thicker letters with no extra meaning, raw <b> is the honest choice. That is one of the differences covered in Markdown versus HTML.
Why the asterisk form wins
Use two asterisks. Underscores are a trap in three separate ways:
- They collide with
snake_caseidentifiers and file names. - They refuse to work inside a word.
- On Discord,
__text__means underline rather than bold.
Pick ** and all three problems vanish at once. The Discord reference covers the rest of that platform's quirks.
Italic with one asterisk
One marker instead of two gives italic, and again both characters work:
Read the *entire* changelog first.
Read the _entire_ changelog first.The output is <em>, which means stressed emphasis. It is the word you would say louder.
What italic should and should not carry
Some screen reader setups announce <em>, so keep it for text that really is emphatic. Titles, foreign words and interface labels are a different job:
- Genuine stress on a word: use
*asterisks*. - A book or film title: raw
<cite>says what you mean. - A term you are defining: italics are fine, and readers expect them.
- A button or menu name: plain text or
<i>beats emphasis.
The same marker advice applies here: prefer *. A file full of _italic_ is one pasted Python variable name away from a formatting accident.
Why asterisks beat underscores, and the space trap
Underscores do not work inside a word
CommonMark restricts underscores on purpose, so that identifiers survive. An underscore run with letters on both sides can neither open nor close emphasis. An asterisk run has no such limit:
un*frigging*believable -> un<em>frigging</em>believable
un_frigging_believable -> literal text, no italicsThe payoff is that snake_case_words, __init__ and my_file_name.txt come through untouched in CommonMark and GitHub Flavored Markdown.
Older engines do italicise the middle of those, including the original Markdown.pl and a number of wikis. That is why a legacy README sometimes shows case in the middle of a variable name. The safe habit is backticks, since `snake_case_words` is both correct and readable.
The space trap
A delimiter with whitespace on its inner side cannot open or close emphasis. This is the most common emphasis failure of all:
** bold ** -> prints the asterisks
**bold** -> boldThe markers must hug the text. Whitespace on the outside is fine and usually necessary, so a **bold** word is correct.
Escaping a literal asterisk or underscore
Put a backslash in front of it:
5 \* 3 = 15
The file is called report\_final.mdTip: For anything code-shaped, reach for backticks before backslashes. Nothing inside a code span needs escaping, it survives copy and paste, and it tells the reader what the text is. The code blocks reference covers inline code and fences in full.
Bold italic, nesting, links and headings
Three markers give both at once, and mixing the two characters is the most readable form:
***bold and italic***
___bold and italic___
**_bold and italic_**All three render as bold italic. The last one is worth adopting, because ***word*** is genuinely hard to count at a glance in a diff.
Nesting emphasis inside emphasis
Emphasis nests as long as the inner and outer delimiters differ:
**Warning: *do not* restart the service.**
*A mostly italic line with one **bold** word.*The same character for both levels does not work the way people expect. In *outer *inner* outer* the parser pairs the first two runs, and the result is a mess. Alternate the characters instead, or nest an underscore pair inside an asterisk pair.
Inside links and headings
Emphasis works inside link text and around a whole link:
[**Download the installer**](https://example.com/setup.exe)
**[Download the installer](https://example.com/setup.exe)**Both render bold. The first keeps the markers inside the link, which is tidier when you later edit the URL, and the links reference covers the rest of link syntax.
Bold is not a heading
In a heading, emphasis renders but is stripped out of the generated anchor ID. So ## The **important** part becomes #the-important-part, and the headings reference has the rest of those ID rules.
Never use bold in place of a heading. A bold line gives you no outline entry, no anchor, and nothing for a table of contents to find.
Strikethrough with double tildes
Two tildes on each side draw a line through the text:
~~Ships on Friday~~ Ships on Monday.It renders as <del>, which marks deleted content. That reads correctly for a changed price, a completed task or a superseded date.
Where the tildes work, and how many
Strikethrough is not part of original Markdown or of core CommonMark. It arrived as a GFM extension, so the count varies by platform:
- Two tildes on GitHub, GitLab, Discord, Reddit, Obsidian, Notion and most note apps.
- One tilde is also accepted by GFM, and Slack uses exactly one.
- Neither in a strict CommonMark renderer, which prints the tildes as text.
Where the extension is missing, <del>text</del> works anywhere inline HTML is allowed.
Highlight, underline, superscript and subscript
Highlight
==highlighted== is not standard Markdown. It works in Obsidian, in Typora, and in MkDocs Material with the pymdownx.mark extension. GitHub prints the equals signs verbatim. The portable version is <mark>highlighted</mark>.
Underline
Markdown has no underline syntax, and the omission is deliberate. On the web an underline means a link, so underlining ordinary text confuses readers.
If you need it anyway, use <u>text</u>. For an edit that was inserted, <ins>text</ins> is better. Discord is the exception that catches people out, since it reads __text__ as underline where every other tool reads it as bold.
Superscript and subscript
<sup> and <sub> are the reliable route and work on GitHub. Pandoc and several markdown-it setups add ^text^ and ~text~, but the subscript form collides with single-tilde strikethrough, so avoid it in shared files.
E = mc<sup>2</sup> and H<sub>2</sub>OEvery emphasis syntax, and where it works
The table below lists each marker, the HTML it produces, and the platforms that understand it.
| Syntax | Result | HTML | Where it works |
|---|---|---|---|
**bold** | bold | <strong> | Everywhere |
__bold__ | bold | <strong> | Everywhere except Discord, where it underlines |
*italic* | italic | <em> | Everywhere |
_italic_ | italic | <em> | Everywhere, but never inside a word |
***both*** | both | <strong><em> | Everywhere |
**_both_** | both | <strong><em> | Everywhere, easiest to read in source |
~~gone~~ | <del> | GFM, GitLab, Discord, Reddit, Obsidian, Notion | |
~gone~ | <del> | GFM and Slack; means subscript in Pandoc | |
==marked== | marked | <mark> | Obsidian, Typora, MkDocs Material; literal on GitHub |
<mark>marked</mark> | marked | <mark> | Anywhere inline HTML is allowed |
<u>under</u> | under | <u> | Anywhere inline HTML is allowed; no Markdown equivalent |
<sup>2</sup> | x2 | <sup> | GitHub, GitLab, most site generators |
^2^ and ~2~ | x2, H2O | <sup> <sub> | Pandoc and markdown-it plugins; literal on GitHub |
un*frig*believable | unfrigbelievable | <em> | Everywhere; the underscore form does nothing |
snake_case_words | snake_case_words | plain text | CommonMark and GFM; italicised by some legacy engines |
Emphasis with Chinese, Japanese and Korean text
The usual complaint is that **粗體** sometimes refuses to render. It is not a font problem and it is not a bug in your editor. It is one CommonMark rule meeting full-width punctuation.
Plain CJK bold is fine
Simple cases work in any modern CommonMark or GFM parser, even with no spaces anywhere in the line:
這是**粗體**文字 -> renders boldWhy the brackets version fails
CommonMark decides whether a delimiter may open or close by looking at the character on each side of it. A marker run that is followed by punctuation and preceded by a letter is allowed to do neither. Full-width brackets are punctuation, so this happens:
他說**「這樣」**才對 -> asterisks print as text
他說「**這樣**」才對 -> renders boldThe two lines look almost identical in an editor. Only the position of the brackets changed, and that is the whole difference between working bold and four visible asterisks.
Three fixes, best first
- Move the punctuation outside the markers. Write
「**這樣**」, not**「這樣」**. Nothing else changes, and the sentence reads the same. - Add a space before the opening run. It works, but it changes the spacing of a Chinese sentence, which most editors will not accept.
- Drop to raw HTML.
<strong>「這樣」</strong>always works, wherever inline HTML is allowed.
Underscores fail far more often on CJK
Several engines treat CJK characters as word characters. __粗體__ pressed against the text around it then looks like mid-word emphasis, which underscores are not allowed to do. Older Chinese-language blog platforms are the usual offenders.
Watch out: the safe combination is ** plus punctuation outside the markers, then a preview before you publish. Our editor renders CJK exactly as GitHub does, so what you see there is what a reader gets. Writers working in Chinese will also want the full-width bracket trap in the links reference, which is the same problem in a different element.
Common mistakes and their fixes
Six mistakes cover nearly every piece of emphasis that will not render:
- Spaces inside the markers, which stops them opening or closing.
- Underscores used mid-word, where CommonMark refuses to emphasise at all.
- Unmatched delimiters, which leave asterisks on screen.
- Bold standing in for a heading, with no outline entry and no anchor.
- Strikethrough where the extension does not exist.
- Emphasis doing the work of structure, so nothing stands out.
Spacing and unmatched markers
Broken, then fixed:
** Important ** notice
**Important** noticeTwo opening markers and one closing marker leave asterisks on screen, and often swallow the rest of the sentence. Broken, then fixed:
**Note: the API key *is required.
**Note:** the API key *is* required.Underscores in the middle of a word
Nothing renders, because underscores cannot open inside a word. Broken, then fixed with asterisks:
re_start_ the service
re*start* the serviceBold used where a heading belongs
A bold line looks like a heading and behaves like nothing. Broken, then fixed:
**Configuration**
### ConfigurationEmphasis instead of structure
A paragraph with six bold phrases in it emphasises nothing at all. Bold one term per idea. Use lists when the content is really a list, and a blockquote when it is really a quotation.
Strikethrough belongs on the same list. If tildes print as text, the renderer is plain CommonMark, so use <del>superseded</del> or check the GFM reference for what that platform supports.
Debugging emphasis that will not render
Paste the line into the editor and delete characters until it works. The culprit is nearly always a space or an unmatched marker.
The cheat sheet keeps all of these on one page, the complete Markdown guide puts emphasis next to every other element, and what Markdown is explains why the format keeps its own formatting readable as plain text.
Support data verified
Frequently Asked Questions
Should I use asterisks or underscores for bold in Markdown?
Use asterisks. **bold** and __bold__ produce identical HTML, but underscores cannot emphasise inside a word, they collide with snake_case identifiers, and on Discord __text__ means underline rather than bold. Asterisks avoid all three problems.
Why is my Markdown bold not working?
Usually a space on the inside of a marker: ** bold ** renders as literal asterisks, while **bold** works. The other causes are an unmatched pair, and underscores used inside a word, which CommonMark refuses to treat as emphasis at all.
How do I write bold and italic at the same time?
Three markers on each side: ***bold italic***. Mixing characters as **_bold italic_** renders identically and is much easier to read in the source, which matters when you are counting asterisks in a diff.
Does strikethrough work everywhere in Markdown?
No. ~~text~~ is a GitHub Flavored Markdown extension, not part of original Markdown or core CommonMark. GitHub, GitLab, Discord, Reddit, Obsidian and most note apps support it; a strict CommonMark renderer prints the tildes. Use <del>text</del> where the extension is missing.
Why does bold sometimes fail on Chinese text?
Because CommonMark decides whether a delimiter can open or close from the characters on either side, and full-width punctuation immediately inside the markers blocks it. 他說**「這樣」**才對 fails while 他說「**這樣**」才對 works. Move the punctuation outside the markers, or use <strong>.
Can Markdown do colored text?
No. Plain Markdown has no syntax for colour at all, because it marks up structure and leaves appearance to the renderer's stylesheet. The workaround is inline HTML, <span style="color:red">text</span>, which does work in several editors and static site generators. On GitHub it simply will not work, because GFM strips style attributes for security, so a README has to signal importance with bold, an emoji or a GFM alert box instead.
How do I center text in Markdown?
Markdown has no centring syntax either, so the answer is inline HTML: wrap the text in <p align="center"> or <div align="center">. GitHub does allow the align attribute, unlike inline style, which is why so many READMEs centre their logo and badges this way. Leave a blank line above and below the tag, and note that some parsers ignore Markdown syntax inside a block-level HTML element, a rule the complete guide spells out.
How do I strikethrough text in Markdown?
Wrap the words in two tildes on each side, like ~~this text is struck through~~. That is the whole syntax, and it works mid-sentence, inside list items and inside table cells. The catch is that strikethrough is a GitHub Flavored Markdown extension that never made it into original Markdown or CommonMark, so a strict parser prints the tildes and strikes out nothing.
Keep learning
Try the Editor
Try the Editor