The URL encode tool converts a text string into a form suitable for inclusion in a URL. This form is called “percent encoding” or “URL encoding.” The URL decode tool converts an encoded string back.
Encode: In the text box, enter text that will be included in a URL parameter. Click the “URL encode” radio button and then “Go.” Don’t give the tool a full URL, or you won’t get correct results.
Decode: Enter URL-encoded text in the text box. This can be a full URL or part of one. Click the “URL encode” radio button and then “Go.”
When to use it
A URL can contain parameters which include syntactic markers. If they’re just entered as they are, the browser will parse them incorrectly. For example, you might have a URL with the parameter
text=one two three
If this goes into a URL without change:
http://www.example.com?text=one two three
and you use that in a link, the server will have trouble, since a space terminates the URL. URL encoding converts unsafe characters into an encoded form so that
The URL decoding tool is useful when you find a URL with encoded characters in a file and want to see what it looks like as plain text.
URL encoding can also be used for cookie values in HTTP headers and data in POST requests.
What it does
The URL encoding tool takes a string and converts it to URL-encoded format, also known as percent-encoded format. It treats any non-ASCII characters as UTF-8. The URL decoding tool takes a string with URL-encoded characters and converts it back to the unencoded format.
A deeper look
The term “URL encoding” is common but slightly inaccurate. The encoding applies to the more general category of Uniform Resource Identifiers (URIs), including Uniform Resource Names (URNs).
URL parameter values can include ASCII alphanumeric characters without difficulty. However, certain characters are “reserved” and have to be encoded to ensure correct interpretation of the URL. URL encoding should not be done anywhere except in parameter values. A character is encoded by replacing it with a percent sign followed by its two-digit hexadecimal encoding.
All characters other than “safe” ones are replaced in a URL encoding. The only safe characters are the upper and lower case ASCII letters, digits, and the characters
$ – _ . + ! * ‘ ( ) ,
All other characters, including non-printing characters and anything outside 7-bit ASCII, need to be URL encoded to guarantee safety.
Other characters can be URL encoded, but there’s no benefit and some risk. If the software on the server side isn’t expecting encoded characters and doesn’t decode them, it might not act properly. Granted, this is a bug, but there’s no reason to seek out buggy behavior unless you’re a tester.
URL encoding can also be used for the domain name portion of a URL. However, W3C recommends using Punycode, which is optimized for domain names. Don’t use the encoding tool to convert a domain name, since this will convert the periods and break the URL.
A drawback to URL encoding is that it adds to the URL’s length. There is no official limit on the length, but 2000 characters is generally considered the maximum safe length. You generally don’t know exactly what parameter values will be sent, but you should allow for possible URL encoding when making estimates. If a URL with all its parameters might exceed 2000 characters, go with a POST rather than a GET request.
The URL encoding tool assumes it’s getting ASCII or UTF-8 text. However, the encoding itself doesn’t assume any character set. It’s simply bytes which the server can interpret however it’s programmed to. It can be interpreted as UTF-8, Latin-1, or anything else. While most websites today expect UTF-8, nothing requires them to. Some older websites will interpret URL parameters in Latin-1, Microsoft Windows-1252, or other encodings.
All values from 0 (%00) to 255 (%FF) can be URL-encoded, so binary data can be passed in a URL parameter. Binary data doesn’t need to have every byte encoded; it’s more efficient to pass hex 41 as “A” rather than “%41”.
The encode tool should be used only with single URL parameters. Encoding a full URL or even a parameter string will encode special characters such as “?” and “=”, making them ordinary text rather than part of the URL syntax.
In HTTP POST requests, form fields are sent as data following the request, rather than as part of the URL. By default they use the
application/x-www-form-urlencodedInternet media type. It looks like the query portion of a URL, but there’s no limit on its length. It uses URL encoding in the same way. Form data submitted as
multipart/form-datacan also use URL encoding.
HTTP headers which set cookies need to have a few characters URL encoded to avoid syntactic problems. It doesn’t hurt to do the normal encoding, though it increases the data size slightly.
Decoding a full URL is safe, since only the parameter values should use URL encoding and everything else will be left alone.
The first specification for URL syntax came out in 1994, when ASCII was considered good enough for almost everything. As a result, various hacks have been needed to support arbitrary URL parameters and international languages. URL encoding is an imperfect but widely used solution.