There seems to be a problem with making a clickable archive.org URL. For example:

See the history for the site at archive.org.

I am using Chrome. I suspect something about the * in the URL, perhaps because it gets encoded as %2a, causes the URL request to be sent to the current site (meta.stackoverflow.com) which doesn't make sense.

  • @lunboks: I just tried the link with Firefox and Internet Explorer, and they both fail in the same way. Commented Feb 10, 2014 at 21:00
  • 1
    You're right. I just noticed that archive.org responds with a Frankensteined redirect based on the referrer for whatever reason. I have referrers turned off which is why it "worked" for me with Firefox.
    – a cat
    Commented Feb 10, 2014 at 21:45
  • I reported the same problem on Web Applications Meta SE: Percent-encoding of asterisks (*) in links. And see also here on mSO: A star in a URL breaks the linkification in posts
    – unor
    Commented Feb 10, 2014 at 22:28
  • @lunboks: Oh, wow, that's pretty crazy. Where do we send bug reports for archive.org? (That said, SE is also wrong in escaping the asterisk, since it's a reserved character per RFC 3986.) Commented Feb 11, 2014 at 15:53
  • FWIW the archive.org bug is now fixed. Commented Jan 16, 2016 at 23:57

1 Answer 1


From the next build on, we've added $ (dollar sign), [ and ] (square brackets), and * (asterisk) to the whitelisted characters that we allow to appear unencoded in links. It's debatable whether that's necessary or legal or unnecessary or illegal by the standard, because the RFC situation is horribly confusing in this regard. In particular the square brackets are a strange beast.

However, since there are advantages like certain sites simply not accepting encoded asterisks (your archive.org is one example; Google is another one), and plain readability of links, and since whatever is necessary to make sure URLs are transported over the network correctly is done by the browsers anyway, I consider this a good change. A major reason for encoding those characters was the potential of collsion with characters that have special meaning in Markdown, but that problem can be solved in another way.

Note that there is no change to free-form link recognition (a.k.a. "this looks like a URL, let's link it").

But if you explicitly make it a link (with angle brackets, or [...](...) syntax, or Ctrl-L, etc.), these characters will not be automatically percent-encoded anymore (again, next build).

You must log in to answer this question.

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