URL Encoder / Decoder

URLs were designed in the early days of the internet with strict rules about which characters could appear in them. The original specification only allows letters, numbers, and a handful of symbols like hyphens and underscores. Everything else, including spaces, ampersands, question marks, and even non-English characters, needs to be converted into a format the web can understand.

This conversion process is called percent-encoding. When you type a search query into Google that contains a space, your browser secretly converts that space into %20 before sending the request. The server on the other end knows to read %20 as a space. Without this encoding, URLs would break because certain characters have special meanings. An ampersand separates query parameters, a question mark signals the start of parameters, and a hash symbol jumps to page sections. If your actual data contains these characters, they must be disguised.

This tool handles both directions of that conversion. Paste in regular text with special characters, and it encodes them for safe URL use. Paste in a jumbled string of percent signs and hex codes, and it decodes them back to readable text.

The encoding process follows a straightforward pattern. Each problematic character gets converted to its ASCII code number, then that number is written in hexadecimal and prefixed with a percent sign. A space has ASCII code 32, which equals 20 in hexadecimal, so it becomes %20. An ampersand is ASCII 38, which is 26 in hex, giving us %26.

Let's work through a concrete example. Say you want to encode the phrase "price=50&discount=yes" as a single query value. The equals sign has ASCII code 61, which is 3D in hex. The ampersand is 38, or 26 in hex. After encoding, the string becomes price%3D50%26discount%3Dyes. Every reserved character is now safely disguised, and the receiving server can decode it back to the original meaning.

Non-ASCII characters follow a slightly more complex path. They're first converted to UTF-8 bytes, then each byte is percent-encoded. The Japanese character あ, for instance, becomes %E3%81%82 because its UTF-8 representation spans three bytes.

Imagine you're building an application that searches a product database. Your API endpoint looks like this: api.example.com/search?query=shoes&color=red. That works perfectly until a user searches for "red & blue shoes" with an actual ampersand in their query. Suddenly the API returns an error because the ampersand splits the query into unexpected fragments.

You paste "red & blue shoes" into this encoder and get back red%20%26%20blue%20shoes. Now your full URL becomes api.example.com/search?query=red%20%26%20blue%20shoes&color=any. The server receives this, decodes the query parameter, and correctly interprets the search as a single phrase containing an ampersand. Crisis averted.

The reverse situation happens when you're debugging someone else's code. You find a log file showing a request URL with query=user%40email.com%3Fname%3DJohn. Without decoding, this is nearly unreadable. Paste it into the decoder and you instantly see [email protected]?name=John. Now you understand what data was actually being sent and can trace the bug.

One overlooked application involves embedding Base64-encoded data in URLs. Base64 strings often contain plus signs and forward slashes, both of which have special meanings in URLs. If you're passing a Base64 token like abc+def/ghi as a parameter, the plus sign might be interpreted as a space on some servers. Encoding the entire token ensures it arrives intact, becoming abc%2Bdef%2Fghi.

Marketing professionals encounter URL encoding constantly when building tracking links. A campaign URL might need to pass the original destination as a parameter for redirect tracking. If that destination is https://shop.com/sale?discount=20, you must encode the entire thing, colons, slashes, question marks, and all. The result looks chaotic but guarantees the tracking system can extract and redirect to the exact original URL.

Developers working with OAuth and authentication tokens face similar challenges. Access tokens often contain special characters that break if not encoded. Before accusing the API of returning bad tokens, decode them first. You might discover the token is perfectly valid but was double-encoded or truncated due to an unencoded character.

The most common mistake is encoding a string that's already encoded. If you encode hello%20world thinking it contains a space, you get hello%2520world. That %25 is the encoded form of the percent sign itself. When the server decodes this, it sees hello%20world instead of hello world. Your data is now corrupted with a literal percent sign and digits.

Another frequent error comes from using the wrong encoding function in code. If you use encodeURI on a query parameter value that contains reserved characters, those characters pass through unchanged. Someone encoding search=red&blue with encodeURI gets search=red&blue, which still breaks the URL. This tool uses the equivalent of encodeURIComponent, which encodes those reserved characters properly.

Finally, remember that the plus sign has a complicated history. In some older systems, plus signs in query strings represent spaces. In modern encoding, a plus sign encodes to %2B while a space becomes %20. If you're seeing unexpected plus signs or spaces, check which encoding convention the target system expects.