Complete Guide to Markdown Text Styling and Formatting

When people think about Markdown formatting, the first reaction is usually "it's just bold and italic, right?" But once you start writing real documents, questions pop up: Does strikethrough work on every platform? Can bold and italic be combined? Why does ==highlight== show up as plain text on GitHub?

This article focuses specifically on Markdown text styling — covering every syntax that affects how your text looks, explaining platform compatibility differences, and sharing practical formatting tips along the way.

Markdown Styling Quick Reference

Here's a summary table for quick lookups. Each item is explained in detail below.

This table covers essentially every text styling option available in Markdown. Notice that some are native Markdown syntax (bold, italic, strikethrough), while others rely on inline HTML (underline, superscript, subscript). This distinction matters — we'll get into why.

Bold and Italic: The Fundamentals

Bold and italic are the two most commonly used text styles in Markdown, and the syntax is straightforward:

**This is bold text**
*This is italic text*
***This is bold and italic***

Markdown provides two sets of symbols — asterisks (*) and underscores (_) both work:

**bold** or __bold__
*italic* or _italic_

In practice, most people prefer asterisks. The reason is that underscores can conflict with underscores inside words (like some_variable_name), where some parsers might treat them as italic markers [^1].

Bold and italic can be combined. ***text*** gives you bold italic, which is equivalent to **_text_** or ___text___.

Here's a gotcha I ran into on GitHub: when nesting bold and italic inside list items, having spaces between the markers and the text can produce different results across renderers. For example, ** bold ** won't render as bold under the CommonMark spec (because of the spaces inside the markers), even though some editors' live previews show it correctly. My advice: always keep the markers tight against the text, no spaces [^1].

Strikethrough: Marking Deleted or Outdated Content

Strikethrough uses double tildes, as covered in the Markdown strikethrough syntax:

~~This text is crossed out~~

The rendered effect is a horizontal line through the text: This text is crossed out.

This syntax is part of the GitHub Flavored Markdown (GFM) extension, not the CommonMark standard. However, almost every major platform supports it now — GitHub, GitLab, Obsidian, Typora, VS Code, and Discord all work fine. If it doesn't render on some niche platform, that means it doesn't support GFM extensions [^2].

Strikethrough is often paired with bold, especially in changelogs or pricing updates:

~~**Was $199**~~ Now **$99** limited time

Highlight: Adding Background Color to Text

The highlight syntax wraps text with double equals signs:

==This is text that needs emphasis==

This works in note-taking tools like Obsidian, Typora (needs to be enabled in settings), Logseq, and iA Writer — the text gets a yellow background.

However, ==highlight== is not part of any Markdown standard. CommonMark doesn't recognize it, and neither does GFM [^3]. If you write ==highlight== on GitHub or GitLab, it shows up as plain text.

On platforms that don't support it, you can use the HTML <mark> tag instead:

<mark>This is text that needs emphasis</mark>

But GitHub strips most HTML tags, so <mark> doesn't work there either. Honestly, if you need a highlight effect on GitHub, the most reliable workaround is using bold or inline code for emphasis.

For more details on highlighting, check out the Markdown highlight article.

Inline Code: Marking Code or Special Terms

Wrapping text with single backticks creates inline code:

In JavaScript, use `console.log()` to output content.

Inline code renders as monospace font with a gray background. Strictly speaking, it's not a "style" but a semantic marker — it indicates the text is code. But visually it does provide emphasis, and many people use it to mark filenames, commands, keyboard shortcuts, and other special terms.

One important note: Markdown syntax inside inline code is not parsed. So `*this won't be italic*` renders as monospace text with asterisks, not italic text.

If the code content itself contains backticks, use double backticks to wrap it:

`` Code with a ` backtick ``

Combining Styles: How Multiple Formats Work Together

Markdown allows multiple styles to be combined. Common combinations:

**_bold italic_**
~~**strikethrough bold**~~
**`bold code`**
~~*strikethrough italic*~~

But there are rules — not all combinations work:

1. Compatible combinations: bold+italic, strikethrough+bold, strikethrough+italic, bold+inline code
2. Incompatible combinations: inline code cannot contain any Markdown styles (because inline code doesn't parse Markdown)
3. Highlight + other styles: depends on the platform. Obsidian supports ==**highlight bold**==, but many platforms don't

Honestly, I rarely use more than two layers of styling in practice. Two layers is usually enough — anything beyond that hurts readability.

Filling Markdown's Style Gaps with HTML

Markdown's native styling capabilities are limited — there's no underline, no superscript or subscript, no text color. These all require inline HTML [^4].

Underline

<u>This text is underlined</u>

Markdown doesn't have native underline syntax (John Gruber's design philosophy was that underlines are easily confused with links), but the HTML <u> tag is supported by virtually every Markdown renderer. More details are in the Markdown underline article.

Superscript and Subscript

Common in formulas: x<sup>2</sup> + y<sup>2</sup> = z<sup>2</sup>
Chemical formulas: H<sub>2</sub>O

These are especially useful when writing technical documentation — math formulas and chemical equations both need superscripts and subscripts.

Keyboard Key Styling

Press <kbd>Ctrl</kbd> + <kbd>S</kbd> to save

The <kbd> tag renders text with a keyboard key appearance — bordered monospace font. It's commonly used in tutorials and how-to guides.

Text Color

Markdown doesn't natively support text color. The only option is HTML:

<span style="color: red">red text</span>
<span style="color: #0066cc">blue text</span>

But this approach has major limitations — GitHub strips the style attribute entirely, so it won't work at all there. Obsidian and Typora support inline styles and display colors correctly. If you need to change text color, check out the Markdown text color article for a more detailed comparison of approaches.

Platform Compatibility: Will Your Styles Work?

This might be the most frustrating part of Markdown styling. The same document can render very differently across platforms. Here's a compatibility comparison table:

Key takeaways:

GitHub is the strictest. It doesn't support highlight syntax (neither == nor <mark>), and it strips style attributes from virtually all HTML tags. If your document is going on GitHub, the only text styles you can reliably use are bold, italic, strikethrough, and inline code [^2].

Obsidian and Typora are the most permissive. They support nearly every styling syntax, including highlight, HTML inline styles, and custom colors. If you're using these tools, you have the most styling freedom.

Jupyter Notebook sits in the middle. It supports all basic styles and <mark>, but <mark style> for custom colors doesn't work [^3].

Once I pasted a note from Obsidian directly into a GitHub issue, and all the highlights, colors, and underlines disappeared — only bold and italic survived. That's when I learned GitHub's Markdown renderer strictly filters HTML. Since then, I've developed a habit: if a document is going to GitHub, I only use basic styles while writing.

Practical Markdown Styling Tips

Knowing the syntax is one thing — making your documents look good is another. Here are some tips from my own writing experience.

Use Styling Sparingly

In any document, more bold, italic, and strikethrough doesn't mean better. Overuse makes it harder for readers to identify what's actually important. Here's my approach:

• Bold: for key actions, important concepts, and first-occurrence terms
• Italic: for emphasis in tone, English terms in context, book/article titles
• Inline code: for code, commands, filenames, and configuration items
• Strikethrough: only for marking changes or flagging outdated information

Use Headings and Lists Instead of Excessive Inline Styles

Many people like to bold every keyword in every paragraph, but a better approach is to organize content with clear heading levels and structured lists. Headings are the strongest "style" — they don't just change text size visually, they establish a clear hierarchy in the document structure.

For detailed usage of headings, see Markdown headings.

Mind the Special Needs of Different Languages

When writing in English alongside other languages, a few formatting details matter:

1. Spaces between mixed scripts: Adding a space between English and other scripts makes text more readable. For example, "use Markdown 语法" reads better than "use Markdown语法"
2. Consistent punctuation: Make sure you're using the right punctuation marks for your primary language
3. Line length: Keep lines reasonably short for readability in plain text and diff views

Escaping: When Special Characters Shouldn't Be Syntax

If you need to display asterisks, underscores, or other Markdown special characters as themselves, just add a backslash before them:

\*This won't be italic\*
\# This won't be a heading
\~~ This won't be strikethrough \~~

This is called escaping. More details are in the Markdown escape article.

Frequently Asked Questions

What text styles does Markdown natively support?

The CommonMark standard defines only three inline styles: bold (**), italic (*), and inline code (`). Strikethrough, highlight, underline, and text color are all outside the standard [^1] [^3].

Why don't my styles work on GitHub?

GitHub uses its own Markdown renderer that strips most HTML tags and all inline styles. If you use ==highlight==, <mark>, or <span style="color:red">, none of them will work on GitHub. The only reliable text styles on GitHub are bold, italic, strikethrough, and inline code [^2].

Can I mix bold and italic markers?

Yes. **_text_** and ***text*** produce the same effect. However, note that underscores inside words might be interpreted as italic markers — for example, the underscores in some_variable_name could trigger italic formatting in some parsers. Asterisks are safer [^1].

Can Markdown change fonts and font sizes?

Pure Markdown syntax doesn't support this. Typora can modify fonts through theme CSS, Obsidian through CSS snippets, and GitHub doesn't support it at all. If you need to adjust font sizes, see the Markdown font size article.

What are the limitations of combining styles?

Inline code cannot contain any Markdown styles. Bold and italic can be combined with each other, and strikethrough can be combined with bold or italic. Highlight combined with other styles depends on the platform — Obsidian supports it best, other platforms may not.

References

[^1]: CommonMark Spec — Official Markdown specification, defining parsing rules for bold, italic, and core syntax [^2]: GitHub Docs — GitHub Flavored Markdown specification, GitHub's official formatting documentation [^3]: Daring Fireball — Markdown Syntax Documentation, John Gruber's original Markdown specification [^4]: Markdown Guide — Basic Syntax, authoritative Markdown basic syntax reference [^5]: Stack Overflow — How to apply color on text in Markdown, community discussion on text color solutions in Markdown