URL Encoder and Decoder Tool

Use the URL Encoder and Decoder tool to encode or decode a text string in URL. URLs must be encoded identically for global compatibility. A two-step procedure is utilized to map the large variety of characters used globally into the 60 or so allowable characters in a URL:

1. Convert the character string to a byte sequence using the UTF-8 encoding.
2. Convert every byte that isn't an ASCII letter or numeric to %HH, where HH is the byte's hexadecimal value.

For example, the string ¿entiende(s) would be encoded as: %C2%BFentiende%28s%29.

(In UTF-8, the "ç" is encoded as two bytes C3 (hex) and A7 (hex), which are subsequently represented as the three characters "percent c3" and "percent a7," respectively.) This can result in a lengthy URI (up to 9 ASCII characters for a single Unicode letter), however the goal is that browsers will only need to show the decoded form, and many protocols can communicate UTF-8 without the percent HH escaping.

What exactly is URL Encoding?

URL encoding refers to the process of substituting certain characters in a URL with one or more character triplets composed of the percent character " percent " followed by two hexadecimal digits. The numeric value of the replacement character is represented by the triplet's two hexadecimal digits.

The name URL encoding is a bit misleading because the encoding technique may be applied to any URI (Uniform Resource Identifier), including URNs (Uniform Resource Names). As a result, the phrase percent-encoding should be used instead.

Which Characters Can Be Used in a URL?

A URI's characters are either reserved or unreserved (or a percent character as part of a percent-encoding). Reserved characters are ones who have particular meaning at times, whereas unreserved characters do not. Characters that would normally be forbidden are represented by authorized characters when employing percent-encoding. With each version of the standards that govern URIs and URI schemes, the sets of reserved and unreserved characters, as well as the situations under which particular reserved characters have special significance, have altered slightly.

RFC 3986 requires that the characters in a URL be drawn from a predefined set of unreserved and reserved ASCII characters. Other characters are not permitted in a URL.

The unreserved characters can, but should not, be encoded. The unreserved characters are as follows:

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 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 0 1 2 3 4 5 6 7 8 9 - _ . ~

Only under particular conditions may reserved characters be encoded. The reserved characters are as follows:

! * ' ( ) ; : @ & = + $ , / ? % # [ ]

Encoding and Decoding a Text

RFC 3986 does not specify which character encoding table should be used to encode non-ASCII characters (such as the umlauts ä, ö, ü). Because URL encoding comprises a pair of hexadecimal digits, and a pair of hexadecimal digits is equivalent to 8 bits, one of the 8-bit code pages might conceivably be used for non-ASCII characters (e.g. ISO-8859-1 for umlauts).

On the other hand, because each language has its own 8-bit code page, managing all of these multiple 8-bit code pages would be a tedious task. Some languages are too large to fit within an 8-bit code page (e.g. Chinese). As a result, RFC 3629 recommends using the UTF-8 character encoding table for non-ASCII characters. This is taken into consideration by the following utility, which allows you to select between the ASCII character encoding table and the UTF-8 character encoding table. If the ASCII character encoding table is used, a warning notice will appear if the URL encoded/decoded content contains non-ASCII characters.

When and why should URL Encoding be used?

When data entered into HTML forms is submitted, the form field names and values are encoded and transmitted to the server in an HTTP request message using method GET or POST, or, more traditionally, by email. The default encoding is based on an early version of the generic URI percent-encoding rules, with a few tweaks such as newline normalization and replacing spaces with "+" rather than "percent 20." The MIME type of data encoded in this manner is application/x-www-form-urlencoded, which is presently described (although in a very archaic manner) in the HTML and XForms standards. Furthermore, the CGI specification includes guidelines for how web servers decode this sort of data and make it available to applications.

Application/x-www-form-urlencoded data is included in the query component of the request URI when delivered in an HTTP GET request. When data is transferred through HTTP POST or email, it is placed in the message's body, and the name of the media type is provided in the message's Content-Type header.