Have a look at this answer

One of the bolds works, and the other one just turns up as ** in the actual post.

This is the string that isn't working: **x**ml n**ib**

Which renders as: xml nib

  • for clarity, could you put the original string, escaped in backquotes, then show us how it is rendered? I.e.: change the last line of this post to: The string "**x**ml n**ib**" gets rendered like this: xml nib
    – Kip
    Commented Jul 2, 2009 at 2:21
  • We've been collecting markdown bugs in another thread, so I added this one meta.stackexchange.com/questions/1227/… Commented Jul 2, 2009 at 2:27
  • 1
    @Kyle I'm a bit confused as to the status of this... it's marked as "completed" but it's still broken in the same way as before, and the thread you linked is also marked as "completed". Was this actually a "wontfix"?
    – RomanSt
    Commented Mar 11, 2011 at 5:24
  • @romkyns: It's referring to the part of the preview not matching the actual output, as identified by the middle two sentences of this question (pre-revision).
    – animuson StaffMod
    Commented Jul 11, 2013 at 3:58

7 Answers 7


This is not a bug; this is by design.

It becomes very difficult to talk about code when your_variable_names_are_suddenly_underlined. Intra-word emphasis is a bad idea and we have EXPLICITLY disabled it.

See: https://blog.stackoverflow.com/2008/06/three-markdown-gotcha/.

1) Markdown’s single biggest flaw is its intra-word emphasis.

I don’t think anybody writes:


often enough to justify making it nearly impossible to talk about tokens with underscores in them:


is interpreted as:


It even works across word boundaries:

file_one and file_two


file<em>one and file</em> two

Whenever you’re writing tokens with underscores you have to make absolutely sure you’re in a backtick-delimited code span. The same problem will also nail you on equations like abc, but that seems to pop up less frequently.

Showdown follows the reference implementation on all this, but in WMD I do a little preprocessing to hack the idiocy away: basically I just backslash-escape any underscores or asterisks that might trigger it. It’s a flagrant violation of the standard, but since it’s a pre-pass that should produce identical output with any Markdown processor, I feel justified. Unfortunately my hack did screw up one edge case (which I don’t have in front of me) and there isn’t any way to disable it. Both those things will change in the next release.

  • 2
    i guess this is for users who don't know to put backquotes around inline code?
    – Kip
    Commented Jul 2, 2009 at 2:26
  • 9
    Jeff: the problem that many of us have here isn't that the ** characters don't bold the text. It's that the behavior shown by the preview is different from the behavior shown after you post. That is what needs fixed. Commented Jul 2, 2009 at 3:11
  • So why does it work in the javascript preview then? Commented Jul 2, 2009 at 14:29
  • If I click the bold button in the editor, then I expect it to bold my text. If markdown can't do it, and html bold tags can, then the editor should be inserting bold tags.
    – user130231
    Commented Jul 2, 2009 at 23:10
  • @Tom, if you feel strongly about it, you can submit patches to the repository: meta.stackexchange.com/questions/1227/… Commented Jul 3, 2009 at 8:25
  • 1
    Jeff, you seem to have taken the Microsoft-patented "let's hold the poor little idiots' hands" approach to software design. That's rather disappointing. Intraword emphasis is legitimately useful (made-up example: the word is emphasis, not emfasis), whereas underscore-joined names without backticks are not useful. When a user mistakenly types PLAIN_TEXT and sees PLAIN<i>TEXT</i> instead, it's easy to correct (it's a wiki. Just fix it), but when they type intraword emphasis and don't get it, it's not as easy to fix (<b> doesn't immediately come to mind).
    – P Daddy
    Commented Dec 9, 2009 at 23:45
  • 3
    This "answer" maybe justifies disallowing intra-word underscore-emphasis. Maybe. (And only on the techie SE sites.) It in no way, shape, or form justifies disallowing intra-word emphasis via an asterisk. (Does any programming language even allow using asterisks in variable names?)
    – Marti
    Commented May 18, 2011 at 0:20

As a workaround, you could use "**x**ml n<b>ib</b>": xml nib


This used to be intentional for a long time, but now it works. See Markdown change: Intra-word emphasis now works.


xml n ib
xml nib
xml nib

Looks like it doesn't work when bolding partial words, which at times could be useful if you ever need to use ** inside another word sentence.

Unclear which would be better in this case, stats on how often ** is used? :p

abc abc abc

  • 1
    Gosh I wish I were better at pointers now.
    – user3788
    Commented Dec 23, 2009 at 17:35
  • you can use <b></b> Commented Jul 11, 2013 at 10:02

A failing in the markdown parser. It starts a bold if the bold tag starts on a word boundary, but not inside a word.

Xml nIB

But it works in the preview box correctly, so the javascript parser is correct, the server side one is not.


It works good; just put some spaces.

x ml n ib
**x** ml n **ib**

If you want to use it without spaces you could use <b></b>.

xml nib
<b>x</b>ml n<b>ib</b>  

You can also put <o> before the initial ** and after the final **.

aaaa = xml nib
a<o>**aa**<o>a = **x**<o>ml n<o>**ib**


Is a double asterisk a left bracket, or a right bracket, or a single asterisk that's been escaped? It gets worse. A single asterisk can be a left bracket or a right bracket as well. If I remember right, single asterisk indicates italics. No matter how you write the parser, there are going to be complaints.

This text was bracketed by single asterisks.

To see the problem more clearly, consider quoted text inside of CSV. A quote mark can be a left bracket or a right bracket. A double quote is typically an escaped single quote. Quotes cannot be nested.

You must log in to answer this question.