URL Encoder Decoder

**About**  
URL Decode and Encode is a straightforward online tool that performs exactly as its name suggests: it quickly and easily decodes URL-encoded data and encodes data into that format. You can URL encode your data without any hassle or decode it into a human-readable format.

URL encoding, also referred to as "percent-encoding," is a method for encoding information in a Uniform Resource Identifier (URI). While commonly known as URL encoding, it is also used more broadly within the URI framework, which includes both Uniform Resource Locator (URL) and Uniform Resource Name (URN). This method is often utilized for preparing data of the "application/x-www-form-urlencoded" media type, commonly employed in submitting HTML form data through HTTP requests.

**Advanced Options**  
- **Character Set:** Our website uses the UTF-8 character set, ensuring your input data is transmitted in that format. You can change this option if you wish to convert the data to a different character set before encoding. Note that for text data, the encoding scheme does not contain the character set, so you may need to specify the appropriate set during decoding. For files, the binary option is the default and omits any conversion, which is required for all formats except plain text documents.
 
- **Newline Separator:** Unix and Windows systems utilize different line break characters. Before encoding, the selected option will replace either variant within your data. For the files section, this is somewhat irrelevant since files already include the appropriate separators, but you can define which one to use for functions like "encode each line separately" and "split lines into chunks."
 
- **Encode Each Line Separately:** This option ensures even newline characters are converted to their percent-encoded forms. Use it if you want to encode multiple independent data entries separated by line breaks.
 
- **Split Lines Into Chunks:** This option transforms the encoded data into continuous text without whitespaces, breaking it into multiple lines based on the character limit defined in the MIME (RFC 2045) specification, which states that encoded lines must not exceed 76 characters.
 
- **Live Mode:** Enabling this option allows immediate encoding of the entered data using your browser's built-in JavaScript functions without sending any information to our servers. Currently, this mode only supports the UTF-8 character set.

*Note: These options cannot be enabled simultaneously, as the resulting output would be invalid for most applications.*

**Safe and Secure**  
All communications with our servers are conducted through secure SSL encrypted connections (HTTPS). We promptly delete uploaded files after processing, and the resulting downloadable file is removed after the first download attempt or 15 minutes of inactivity (whichever comes first). We do not store or inspect the contents of submitted data or uploaded files. For more details, please refer to our privacy policy.

**Completely Free**  
Our tool is completely free to use. You no longer need to download any software for such simple tasks.

**Details of URL Encoding**  
**Types of URI Characters**  
The characters permitted in a URI can be categorized as reserved or unreserved (or as a percent character as part of percent-encoding). Reserved characters are those that sometimes hold special meaning. For instance, forward slash characters are used to separate various parts of a URL (or more generally, a URI). Unreserved characters do not carry any such special meanings. When using percent-encoding, reserved characters are represented by special character sequences. The sets of reserved and unreserved characters, along with the circumstances under which specific reserved characters have special meanings, have slightly evolved with each revision of the specifications governing URIs and URI schemes.

- **Reserved Characters (RFC 3986 section 2.2, January 2005):**
 ! * ' ( ) ; : @ & = + $ , / ? # [ ]

- **Unreserved Characters (RFC 3986 section 2.3, January 2005):**
 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 - _ . ~

Other characters in a URI must be percent-encoded.

**Percent-Encoding Reserved Characters**  
When a reserved character has special meaning in a specific context, and a URI scheme indicates that the character is needed for some other purpose, it must be percent-encoded. This process involves converting the character to its corresponding byte value in ASCII and representing that value as a pair of hexadecimal digits. The digits, preceded by a percent sign ("%"), are then used in the URI instead of the reserved character. For non-ASCII characters, it is typically converted to its byte sequence in UTF-8, with each byte value represented as described above.

For example, the reserved character "/" when used in the "path" component of a URI has special significance as a delimiter between path segments. If a URI scheme dictates that "/" must appear in a path segment, it must be replaced with the three characters "%2F" (or "%2f").

- **Reserved Characters After Percent-Encoding:**
 ! # $ & ' ( ) * + , / : ; = ? @ [ ]  
 %21 %23 %24 %26 %27 %28 %29 %2A %2B %2C %2F %3A %3B %3D %3F %40 %5B %5D

Reserved characters that lack a specific purpose in a particular context may also be percent-encoded, although they do not differ semantically from other characters.

In the "query" component of a URI (the part after the "?" character), for example, "/" is still regarded as a reserved character but typically has no reserved purpose (unless a specific URI scheme states otherwise). Therefore, the character does not need to be percent-encoded when it has no reserved purpose.

URIs that differ solely by the percent-encoding of a reserved character are usually considered non-equivalent unless the reserved character has no special purpose. This determination depends on the rules established for reserved characters by individual URI schemes.

**Percent-Encoding Unreserved Characters**  
Characters from the unreserved set never require percent-encoding.

URIs that differ only by the percent-encoding of an unreserved character are considered equivalent by definition; however, URI processors may not always treat them as such in practice. For maximum interoperability, URI producers are discouraged from percent-encoding unreserved characters.

**Percent-Encoding the Percent Character**  
Since the percent ("%") character indicates percent-encoded octets, it must be percent-encoded as "%25" for that octet to be used as data within a URI.

**Percent-Encoding Arbitrary Data**  
Most URI schemes involve representing arbitrary data, such as an IP address or file system path, as components of a URI. Specifications for URI schemes should provide a clear mapping between URI characters and all possible data values represented by those characters.

**Binary Data**  
Since the release of RFC 1738 in 1994, it has been specified that schemes representing binary data in a URI must segment the data into 8-bit bytes and percent-encode each byte as previously described. For example, byte value 0F (hexadecimal) should be represented by "%0F," but byte value 41 (hexadecimal) can be represented as "A" or "%41." Using unencoded characters for alphanumeric and other unreserved characters is typically preferred for shorter URLs.

**Character Data**  
The method for percent-encoding binary data has often been extrapolated to apply to character-based data, sometimes inappropriately or without clear specification. During the early years of the World Wide Web, when dealing with data characters in the ASCII repertoire and using their corresponding bytes as a basis for determining percent-encoded sequences, this practice was relatively harmless. However, the need to represent characters beyond the ASCII range grew rapidly, and URI schemes and protocols often failed to provide standard rules for preparing character data for URI inclusion. Consequently, various multi-byte, stateful, and non-ASCII-compatible encodings began leading to ambiguities and difficulties in reliably interpreting URIs.

Many URI schemes and protocols presume that data characters will be converted to bytes according to an unspecified character encoding before being represented in a URI by unreserved characters or percent-encoded bytes. If a scheme does not allow the URI to provide hints about the encoding used, or if the encoding conflicts with the use of ASCII for percent-encoding reserved and unreserved characters, the URI cannot be reliably interpreted. Some schemes neglect encoding altogether, suggesting that data characters directly map to URI characters, leaving it up to individual users to determine whether and how to percent-encode data characters not in the reserved or unreserved sets.

- **Common Characters After Percent-Encoding (ASCII or UTF-8 based):**
 newline space " % - . < > \ ^ _ ` { | } ~  
 %0A or %0D or %0D%0A %20 %22 %25 %2D %2E %3C %3E %5C %5E %5F %60 %7B %7C %7D %7E

Arbitrary character data is sometimes percent-encoded for non-URI applications, such as password obfuscation programs or other system-specific translation protocols.