URL Encoder Decoder

Formula

Encode: output = encodeURIComponent(input) | Decode: output = decodeURIComponent(input)

Encoding applies RFC 3986 percent-encoding to unsafe URL characters; decoding reverses valid percent-encoded sequences back to plain text.

Worked Examples

Example 1: Encoding a Search Query Before Appending It to a URL

Problem:You want to pass the raw string search?q=blue shoes&size=10 as a single query parameter value. Pasted directly into a URL it would break, because the question mark would start a new query section and the ampersand would split it into separate parameters.

Solution:Click Encode. Each reserved character is replaced by a percent sign plus its two-digit hexadecimal byte value: the question mark becomes %3F, each equals sign becomes %3D, the space becomes %20, and the ampersand becomes %26. Letters, digits, and the hyphen are unreserved and pass through untouched.

Result:search%3Fq%3Dblue%20shoes%26size%3D10 - now safe to drop into a parameter such as ?query=search%3Fq%3Dblue%20shoes%26size%3D10

Example 2: Decoding a Fully Escaped URL From a Log File

Problem:A server access log or a redirect parameter contains https%3A%2F%2Fexample.com%2Fpath%3Fa%3D1%26b%3D2 and you need to read the original address it points to.

Solution:Paste the string and click Decode. Every percent triplet is converted back to the byte it represents: %3A becomes a colon, %2F becomes a forward slash, %3F becomes a question mark, %3D becomes an equals sign, and %26 becomes an ampersand. Note that the slashes were escaped at all because the URL was encoded as a component value rather than as a whole address.

Result:https://example.com/path?a=1&b=2

Frequently Asked Questions

How does URL encoding work?

URL encoding (percent-encoding) converts characters into a format that can be transmitted over the Internet. It replaces unsafe ASCII characters with a "%" followed by two hexadecimal digits.

Why do I need to encode URLs?

URLs can only be sent over the Internet using the ASCII character-set. If a URL contains special characters (like spaces, &, #), they must be encoded to avoid breaking the URL structure or query parameters.

What is the difference between encodeURI and encodeURIComponent?

This tool uses `encodeURIComponent`, which encodes characters like `/`, `?`, `&` that have special meaning in a URL. `encodeURI` would leave those intact, assuming you are encoding a full URL, not just a parameter.

Can I decode a URL here?

Yes, simply paste the encoded text and click 'Decode' to revert it to human-readable text.

What happens if I decode an invalid URL?

The tool will display an 'Invalid encoded URL' error if the input contains malformed percent-encoding sequences.

Background & Theory

Percent-encoding exists because a URL is not free text, it is a structured expression in which certain characters carry grammatical meaning. A question mark opens the query section, an ampersand separates parameters, an equals sign binds a key to a value, a slash divides path segments, and a hash begins the fragment. RFC 3986 calls these reserved characters. When such a character is meant as literal data rather than as punctuation, it must be escaped, otherwise a parser will read your data as structure and the address silently splits apart. The complement is the unreserved set, defined as the ASCII letters, the digits, and the four marks hyphen, period, underscore, and tilde, which are guaranteed safe and are never escaped. The escape mechanism itself operates on bytes rather than characters, which is the detail most people miss. A character is first serialized to UTF-8, then each resulting byte is written as a percent sign followed by two hexadecimal digits. Characters outside ASCII therefore expand into multiple triplets. Two practical hazards follow. Double encoding happens when already-escaped text is encoded again, turning a percent sign into %25 and producing strings like %2520 that arrive at the server as literal garbage. Scope confusion is the other: encoding a whole URL preserves its structural slashes and colons, while encoding a single parameter value must escape them, which is exactly the distinction between the encodeURI and encodeURIComponent functions.

History

Percent-encoding is nearly as old as the web itself. Tim Berners-Lee described the convention in RFC 1630 in June 1994, and it was formally specified later that year in RFC 1738, the Uniform Resource Locators standard he wrote with Larry Masinter and Mark McCahill. The design constraint was blunt: the networks and mail gateways of the era could only be trusted with a narrow band of ASCII, so any character that might be altered in transit had to be represented using characters that would not. The percent sign was chosen as the escape marker precisely because it had no other role in the URL grammar. RFC 2396 refined the scheme in 1998, but the version in use today is RFC 3986, published in January 2005 by Berners-Lee, Roy Fielding, and Larry Masinter and designated Internet Standard 66. Its most consequential contribution was settling the question of non-ASCII text by mandating UTF-8 as the byte encoding before escaping, ending years of inconsistent charset guessing between browsers and servers. JavaScript gained the matching encodeURI and encodeURIComponent functions in ECMAScript 3 in 1999, replacing the older escape function that mishandled non-Latin characters. The WHATWG URL Standard now maintains the browser-facing behavior as a living specification, reconciling the RFC with what implementations actually do.