https://stackoverflow.com/tools/ shows that a tag named was created in the last 2 days. Clicking on the link for that tag takes one to a page showing "0 Questions tagged "; it treats them as two separate tags, despite the + being encoded as %2b in the URL.

  • Very interestingly, the tag pages fetch the correct tag despite also rendering it as [n] [1] in the sidebar, and you can switch tabs and it'll retain it properly. This is also currently the only way you'll be able to easily find the question with that tag, due to the search oddities elaborated in this report. Normally, you can't even view these pages if you supply multiple tags.
    – Grace Note StaffMod
    Feb 3, 2011 at 17:59
  • 3
    This has come up again. The tag says ruby+cucumber, but it's immediately expanded to [ruby][cucumber] when clicking on it.
    – Kerrek SB
    Aug 16, 2012 at 12:17
  • 2
    There are many tags on SO with + in them including [c++] and [c++-amp]. What is different about the "buggy" tags that makes them behave differently from these long-established tags? Jun 23, 2013 at 14:06
  • 2
    @Kate only "++" are treated properly, e.g. n++1 is not splitted like n+1. Guess the dev team put hard coded exception for "++" but not just for single "+". Jun 23, 2013 at 14:22

1 Answer 1


It's not exactly hard-coded, but rather a switch on how we should split the path into an array of tags. They can either be split by %20 or by +. The '+' character is tricky because there is no definitive standard for encoding spaces, and they can be encoded either as + or as %20. Because URL-encoding is an important part of XSS defense, it makes it tricky to know when to encode a space as %20 or as +, and even worse, whether when looking at a + if it was an encoded space or if it is an unencoded +. The only way to deal with it is to try and construct general categories of use and deal with edge cases as they arise.


Sorry for the delay here. I got busy on other projects and some of the bugs I grabbed got put on the back burner. Anyway, I may have spoken too soon. Generally speaking, tags with the + character are not allowed. There are notable exceptions ( being an obvious one), and those are the ones we work around. This isn't one of those. In fact, I don't think this tag ever got created. There's no history for it at all. In the case that a user really must have a + in the tag, the recommended workaround is to use 'plus' instead. So if there are questions about some technology called Hellfire+Love and that's how everyone searches for it, then the tag would need to be hellfire-plus-love.

Also, for searching posts over tags, the rule is that if any tag in the search has a + in it, you must use a space as a delimiter. See also: https://meta.stackexchange.com/a/47191/136973

  • 2
    I'm sorry, but this is just wrong on so many levels. There is a "definitive standard for encoding spaces", and if you find it "tricky" to tell encoded spaces and plus signs apart, that just means there's a bug (or several) in your code (or possibly in your design). Jan 18, 2014 at 15:45
  • 2
    Ps. A possible source of confusion is that the rules are (slightly) different in the path and query parts of the URL: in the path, a literal + is just a plus sign, in the query it encodes a space. Fortunately, this is the only difference -- in particular, %20 always means a space, and %2B always means a plus sign. As long as your URL-encoding code always encodes spaces and plus signs as %20 and %2B respectively, it will work for all parts of URLs. Jan 18, 2014 at 15:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .