Follow below steps to quickly percent encode a string or URL:
Step 1: Enter the string or URL in the textbox on left called “Enter URL / string to encode”.
Step 2: Click on the button “Encode” in between the two textboxes.
Step 3: At this point you should be able to see the encoding result in the textbox called “Encoded URL / string” on the right side of the page.
You can customize the algorithm and result using various configuration options available on the page. See below for further details on each option.
Encode as I type: Turn on this toggle if you want to see the encoded version as soon as you type. This method completes the encoding using JavaScript on your local machine and does not require any data to be sent to our servers. The only drawback is that this operates best with UTF-8 character-set and thus conversion to other character-set before percent-encoding is not done.
Encoding method: There are two ways you can perform the percent-encoding for your input:
URL Safe: This is the first and the default option, selecting this option would ensure that only the values provided for query parameters are percent-encoded and the remaining URL including scheme, port, fragments remains in their original form, thus preserving the structure of the URL/string.
Example: http://example.com/?test=100% becomes http://example.com/?test=100%25 after URL Safe encoding
Full Encoding: Use this encoding option if you want to percent-encode everything, perfect if you are dealing with strings.
Example: http://example.com/?test=100% becomes http%3A%2F%2Fexample.com%2F%3Ftest%3D100%25 after Full Encoding
Newline character: This option allows you to set the newline character to either Unix style (%0A) or Windows style (%0D%0A). Note that this feature is useful when you are not encoding each line separately.
Character-set: As our website uses the UTF-8 character set, all input data is transmitted in that format. You can select a different character-set if you want to convert the data to selected character set before encoding. Note that in case of the text data, the encoding scheme does not contain the character set, so you may have to specify the appropriate set during the decoding process as well.
This option is only available if the “Encode as I type” option is disabled. This is as we need to send the data to our servers to perform the encoding change.
Encode each line separately: If selected, each input line is encoded separately. Use this option if you have multiple URLs that need to be percent-encoded.
Split in 76 character chunks: If the “Encode each line separately” option toggle is off, the encoded data is a continuous text with line-break character but without any whitespaces, so check this option if you want to break the encoded data into multiple lines. The character limit is set as per the MIME (RFC 2045) specification, which states that the encoded lines must not be more than 76 characters long.
Possibly, the next important question is how safe is using our URL encoder and if we save any input data? Well, we do not save any input data because we do not need to store it for processing. We simply run our algorithms and return the output to you.
If you use the “Encode as I type?” option we don’t even need to send any data to our web servers, everything (input, output, configuration) remains on your browser only.
Moreover, we use HTTPS, which is a secure and encrypted way of sending data from your machine to our server for processing, this further helps to ensure that there is no chance of a middle-man seeing this data.
URL encoding, officially known as percent-encoding, is a method of encoding arbitrary data into ASCII character-set suitable for handling via a URI. Note that URIs only support US/Standard ASCII character-set and thus all other characters outside of it need to be converted to Standard ASCII during encoding.
URL encoding is also used to encode data sent via application/x-www-form-urlencoded media type, often used for submitting HTML form data.
Note: Percent encoding is case-insensitive (not case-sensitive).
Characters in a URI can be classified under two groups called Reserved characters and Unreserved characters.
Reserved characters: Reserved characters are the ones that may have a special meaning attached, e.g., forward slash character / is used to break URL into multiple segments, or the question-mark (?) character that marks the beginning of query string. Reserved characters if present as part of data that needs to be transmitted via URL or upon a form submit should be encoded using the Percent encoding.
Note that reserved characters that do not serve any purpose in a particular context need not be encoded, even if encoded they will have the same meaning as the unencoded form, e.g., \ character after question-mark character ? in a URL.
! | # | $ | & | ' | ( | ) | * | + | , | / | : | ; | = | ? | @ | [ | ] |
%21 | %23 | %24 | %26 | %27 | %28 | %29 | %2A | %2B | %2C | %2F | %3A | %3B | %3D | %3F | %40 | %5B | %5D |
Unreserved characters: Unreserved characters do not have any special meaning as far as a URL is concerned. Also, they should not be percent-encoded.
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 | - | . | _ | ~ |
The % character has a special meaning in percent-encoding as it is used as an escape character, thus if present as a part of data, it must be encoded as %25.
The schemes that provide for the representation of binary data in a URI must divide the data into 8-bit bytes and percent-encode each byte. Byte value 0x0F, for example, should be represented by %0F, but byte value 0x41 can be represented by A, or %41. The use of unencoded characters for alphanumeric and other unreserved characters is typically preferred, as it results in shorter URLs.
All characters outside of the ASCII character-set are encoded into UTF-8 before percent-encoding.
When data that has been entered into HTML forms is submitted, the form field names and values are encoded and sent to the server via an HTTP request message using method GET or POST, or, historically, via email. The encoding used by default is based on an early version of the general URI percent-encoding rules, with a number of modifications such as newline normalization and replacing spaces with + instead of %20. The media type of data encoded this way is application/x-www-form-urlencoded, and it is currently defined in the HTML and XForms specifications. In addition, the CGI specification contains rules for how web servers decode data of this type and make it available to applications.
When HTML form data is sent in an HTTP GET request, it is included in the query component of the request URI using the same syntax described above. When sent in an HTTP POST request or via email, the data is placed in the body of the message, and application/x-www-form-urlencoded is included in the message's Content-Type header.
Percent-encoding a character requires converting the character to its byte equivalent in ASCII and representing it as a hex-digit with 0 used as a prefix if there is a single hex-digit. A % symbol is added as a prefix to the 2 digit hex value to denote the combination as an escape sequence.
Note that URIs that differ only by whether a reserved character is percent-encoded or not are normally considered not equivalent (denoting the same resource) unless it is the case that the reserved characters in question have no reserved purpose. This determination is dependent upon the rules established for reserved characters by individual URI schemes.
URIs that differ only by whether an unreserved character is percent-encoded or not are equivalent, but URI processors, in practice, may not always treat them equivalently. For example, URI consumers shouldn't treat "%41" differently from "A" ("%41" is the percent-encoding of "A") or "%7E" differently from "~", but some do. For maximum interoperability, URI producers are therefore discouraged from percent-encoding unreserved characters.
A URL encoder is a critical tool that finds application across almost all software that deal with URLs and need to transfer data between applications, say using API. Test engineers often require to encode/decode data containing URLs and tools as this one come to immediate rescue in such scenarios. Below are a few use-cases where URL encoders can save the day:
Helps prevent errors due to incorrect encoding
Helps form proper URLs with right encoding for data values
Secures and standardizes URLs for use across platforms
Ensures compatibility across systems and APIs by proper encoding
Prevents XSS injection attacks by encoding user provided data values in URL
Many a times, percent-encoding has also been used as a way of obfuscating an otherwise simple string, e.g., email addresses.
You can use our URL Decoder to decode an encoded URL or string. This helps to make the URL human-readable and is an extremely helpful tool for test engineers or if you are just curious about the data contained in a URL.
Here is an example of how a URL changes after percent-encoding:
Original URL: http://example.com/?score=100%
Percent-encoded URL: http://example.com/?score=100%25
Let’s see another example, but this time with a string:
Original string: john.doe@example.com
Percent-encoded string: john.doe%40example.com
URL length is one of the limitations as the encoded URL could be longer than 2000 characters and this could result into some interoperability issues across browsers and servers.
It’s not an encryption technique. While percent-encoding has found application as an obfuscation technique, it must be noted that percent-encoding is a not an encryption technique and as such proper measures should be taken before transmitting any confidential data.