--- title: "Markdown bold and italic: stars, underscores, traps" slug: markdown-bold-italic excerpt: "How to write bold and italic in Markdown with stars or underscores, stack the two, and fix markers that stay visible after rendering." quickAnswer: "This page covers how to mark text as bold or italic in Markdown. It shows the italic and bold forms, how to get both styles at once, and two cases where the markers can stay visible on the rendered page, both covered in the body. It ends with how to print a literal star and a short check for a file that came out wrong. The syntax guide on this blog covers headings, links and other basics." keyTakeaways: - "The first section shows the star and underscore forms for italic and bold." - "A section on stacking bold and italic shows two ways to write the pair." - "The mid-word section explains where stars and underscores part ways, with the spec lines behind it." - "The section on spaces inside the markers shows why some pairs never turn into formatting." - "The closing sections cover printing a literal star and a numbered check for a file that rendered wrong." publishedDate: 2026-10-20 dateModified: 2026-10-20 author: Bobby Huang cluster: B role: post status: published faq: - q: Should I use stars or underscores for italic? a: "The first section compares the two, and the mid-word section shows the case where the choice changes the output." - q: Why does my bold text still show the stars? a: "The section on spaces inside the markers and the numbered check near the end walk through the usual causes." - q: How do I type a star without starting italics? a: "The section on showing a literal star covers backslash escapes and code spans." related: - markdown-syntax-guide - markdown-cheat-sheet - markdown-code-blocks --- You wrapped a word in stars and expected bold. Instead, the stars stay visible after rendering, and the word sits there in plain type. Markdown bold and italic look simple, and usually they are. A few rules about spaces and word edges decide whether each star or underscore acts as a marker. This post covers both marker styles, how to stack bold on italic, and the cases that leave markers on the page. Our basics post, the [Markdown syntax guide](markdown-syntax-guide.md), handles headings, lists, links and the rest. ## Italic and bold with stars or underscores CommonMark gives you two marker characters. In the plain case, one star or one underscore on each side of a word makes italic, which HTML writes as ``. Two on each side make bold, which HTML writes as ``. ```markdown *italic* or _italic_ **bold** or __bold__ ``` Pandoc turns `*italic*` and `_italic_` into the same `italic`. Both bold forms come out as `bold`. The spec's first examples for each rule show the same result for words with nothing odd around them. So which should you pick? For whole words the HTML is identical. Many writers pick stars for both styles, because stars also work inside a word, as the next sections show. Whatever you pick, keep it the same across a file so a person reading the raw text sees one pattern. ## Bold and italic together Three markers on each side give both styles at once. ```markdown ***bold and italic*** ``` The spec turns `***foo***` into an `` wrapped around a ``, and pandoc does the same with the line above. Three underscores also work: pandoc rendered `___bold italic___` with the same nesting. You can also put one style inside the other. That reads more clearly when only part of a phrase needs both. ```markdown **bold with _italic_ inside** *italic with **bold** inside* ``` Pandoc renders the first line as a `` element holding an ``, and the second line the other way round. Using stars for the outer pair and underscores for the inner one, as in the first line, makes it easy to see which marker closes which. ## Markers inside a word This is where the two characters part ways. A star pair can sit inside a word. An underscore pair can't. ```markdown un*believ*able un_believ_able snake_case_name ``` Pandoc renders the first line as `unbelievable`. The second and third lines come out exactly as typed. The spec settles this with two terms. A run of markers is left-flanking when it isn't followed by whitespace, and right-flanking when it isn't preceded by whitespace, with extra conditions when punctuation sits next to it. A star can open italic whenever its run is left-flanking. An underscore has a stricter test: when its run is both left-flanking and right-flanking, as it is between two letters, it can open only if a punctuation character comes right before it. Closing works the mirror way. The spec's own examples show the split. `foo*bar*` becomes italic and `foo_bar_` stays plain. Bold follows suit: `foo**bar**` is bold and `foo__bar__` isn't. The spec gives the reason too. It limits underscores this way so words with inner underscores, like variable names, don't turn italic by accident, and it calls code spans the best home for such names. Two practical results: 1. To style part of a word, use stars. Underscores in that spot stay literal. 2. Don't count on the mid-word rule to protect every name. Underscores at the outer edges of a word still work as markers: pandoc rendered `__init__` as a bold `init`. Put names like that in a code span. ## Spaces inside the markers A space right after the opening marker, or right before the closing one, cancels the pair. ```markdown ** text ** **text ** ``` Both lines come out with the stars still showing. An opening run with whitespace after it isn't left-flanking, so it can't open. A closing run with whitespace before it isn't right-flanking, so it can't close. The spec has an example of each, `** foo bar**` and `**foo bar **`, and both stay as plain text. The fix is to pull the markers tight against the words, as in `**text**`. The same rule keeps spaced-out math readable. Pandoc leaves `5 * 3 * 2` as typed, since every star there has a space on both sides. Watch the first character of a line, though. The spec counts the star as a bullet list marker. Pandoc turned a line reading `* text *` into a one-item list holding `text *`, not a line in italics. ## Showing a literal star or underscore Sometimes you want the character itself on the page. A backslash before it does that. ```markdown \*not italic\* ``` The spec lets any ASCII punctuation character take a backslash escape, and an escaped character loses its Markdown meaning. Pandoc renders the line above as `*not italic*` with no ``. A backslash before an underscore works the same way. Within a code span, the backslash escapes nothing. Pandoc renders `` `\*code\*` `` as `\*code\*`, backslashes included. That's also the upside of a code span: for file paths, glob patterns and variable names, wrapping the text in backticks is often tidier than escaping each character, because code spans bind more tightly than emphasis. Our [code blocks post](markdown-code-blocks.md) covers spans and fences in more depth. ## Checking a file that came out wrong When a phrase renders with stray markers, or italics run further than you meant, go through these checks one by one. 1. **Look at the character next to each marker.** A space between a marker and its word cancels that marker. 2. **Check whether the marker sits inside a word.** If it's an underscore pair inside a word, switch to stars. 3. **Match the characters.** The opening and closing markers must be the same character, so `_foo*` stays plain text. 4. **Check the start of the line.** A star followed by a space at the start can open a list item instead. 5. **Render the file and read the HTML.** On a scratch copy, the command is `pandoc -f commonmark -t html notes.md`. Every `` and `` in the output is a pair the parser accepted, and any star or underscore still in the text is one it skipped. In a test file holding `**out **`, pandoc kept the stars as text, and `*Doe Holdings*` in the next paragraph came out in ``. When an agent produces your files, one plain sentence in its instruction file can save some of these checks, such as "Use stars for bold and italic, and leave no space between a marker and its word." For phrasing tips, read [how to write rules an agent will follow](write-markdown-docs-your-ai-agent-can-follow.md). Some editors may also swap your emphasis characters when they save a file; the post on [save-time reformatting](why-editors-reformat-markdown-on-save.md) shows how that happens. ## Where Sashmark fits Built for reading agent-written Markdown and fixing a stray marker by hand, Sashmark is a desktop program still in the making. It is in development and has not been released. The app itself has no AI features. Its first version should let you change text right on the rendered view, while lines you didn't touch keep their exact bytes. A reload in place after outside edits, with your spot kept, is also in the plan, as is light and dark appearance that follows the system. The [roadmap](/roadmap) tracks progress on each part, and scope is spelled out in the [help pages](/help) along with the [planned features](/features). More about the project is at [sashmark.com](https://www.sashmark.com/).