Which special characters are safe to use in url?

  • 3
    It would be far quicker and easier to ask which special characters are unsafe to use in a URL (as per Andreas Bonini's answer below). Commented Jul 9, 2010 at 13:50
  • 2
    Asking what is unsafe is as hard to answer: Any non-ascii character needs to be percent-encoded.
    – neo
    Commented Jul 9, 2010 at 14:14
  • 2
    @neo: no it doesn't :O Commented Jul 10, 2010 at 1:55

5 Answers 5


The following characters have special meaning in the path component of your URL (the path component is everything before the '?'):

  ";" | "/" | "?"

In addition to those, the following characters have special meaning in the query part of your URL (everything after '?'). Therefore, if they are after the '?' you need to escape them:

  ":" | "@" | "&" | "=" | "+" | "$" | ","

For a more in-depth explanation, see the RFC.

  • 5
    Of course, just for clarity, this answer is the opposite of the question. The question asks for which characters are safe, not those which are unsafe. Since it's hard to answer the original question robustly, the question should probably be edited to ask it the other way around and match this answer. Commented Jul 9, 2010 at 13:49

The safe characters are a-z, A-Z, 0-9, and _ - (underscore and minus), that besides the reserved characters which are used for the parameters.

Other characters will give problems to varying degrees, or with varying frequency. For example: if one parameter is an array ?param=array[content] it will show a URL with the square brackets URL-encoded, which look ugly and impossible to dictate.

But the problem is not only that it's ugly. Let's say you have a JPEG with a character in the name other than the safer ones; many times the browser will be unable to download it, getting a 404. This is a problem for older browsers and some mobile browsers.

How can we test this?

  • put a bunch of images/js/css with the characters you want to test in the names on a public page with many visitors
  • Make the 404 page send you an email every time it gets a hit

I have an inbox with 14,000 emails proving my point.

  • 5
    well, instead of "safe characters" I would say "extremely safe characters" -- the spec allows more, but I agree with you that it's better to be conservative here. Commented Jul 11, 2010 at 3:30
  • 3
    What's wrong with period?
    – BlueWhale
    Commented Jun 7, 2012 at 20:28
  • 2
    can you also explain why . isn't a safe character? Commented May 14, 2021 at 5:21
  • I see edits that could improve this answer, but I hate to remove @JeffAtwood as the last person to edit it 😅
    – iconoclast
    Commented Jan 2, 2023 at 22:55
  • 2
    please feel free to edit @iconoclast! Commented Jan 4, 2023 at 0:42

RFC 2396 is actually obsolete and was superseded by RFC 3986.

The unreserved special characters (safe to use without encoding) (other than letters and digits) are:

- . _ and ~

  • From RFC 3986.: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
    – cskwg
    Commented Dec 24, 2021 at 5:22

This question popped up first, of course, when I googled up "URL safe characters", as most people would. I think it's worthy to put up a straightforward answer to a concise question. From the horse's— ugh, RFC2396— I mean, Sir Timothy's mouth:

2.3. Unreserved Characters

   Data characters that are allowed in a URI but do not have a reserved
   purpose are called unreserved.  These include upper and lower case
   letters, decimal digits, and a limited set of punctuation marks and

      unreserved  = alphanum | mark

      mark        = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"

   Unreserved characters can be escaped without changing the semantics
   of the URI, but this should not be done unless the URI is being used
   in a context that does not allow the unescaped character to appear.

"Upper and lower case letters" in this context are understood as defined earlier in the section 1.6 of the same standard:

The following definitions are common to many elements:

   alpha    = lowalpha | upalpha

   lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
              "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
              "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"

   upalpha  = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
              "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
              "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"

   digit    = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
              "8" | "9"

   alphanum = alpha | digit

So the answer is, URL-safe characters are good old ASCII-7 Latin characters A through Z in lower and upper case, decimal digits 0 through 9, and a handful of non-alphanumerics explicitly enumerated in the mark production rule of the grammar in Sec. 2.3.

If the question is to be understood about the HTTP/HTTPS URL (note that RFC2396 defines the URI), the semantic treatment of the RFC2396 syntax as resource locators for the HTTP[S] protocol is currently standardised by RFC7230, Sec. 2.7. Nevertheless, inferring that the set of "URL-safe" characters is larger than that defined by the RFC2396 from the observation that they are not treated specially in RFC7230 Sec. 2.7 would not be a future-proof move; a possible future RFC7230 update may ascribe semantics to more characters that are outside of the "URL-safe" RFC2396 set, rendering such an inference ex statu quo invalid.

TL;DR, it is the safest and future-proof approach to treat the set of URL-safe characters defined in RFC2396 as the largest possible and non-extensible, and not extend it with those that are currently okay/safe/non-special per RFC7230: this may change. The RFC2396 set, in contrast, cannot.


The answers here are good, but there is one more exception I think is worth mentioning - non-english characters. Referencing this SF question here, characters like ñ (as in Español) are perfectly legitimate, IF they have been encoded in your DNS correctly.

You have to use Punycode within your DNS to get them to resolve in modern browsers (the entry for español is xn--espaol-zwa) but these are now perfectly safe to use in domain names, as they're easy for non-english-speakers to type as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.