🔗 URL Encoder / Decoder

Why URLs Break — And How Percent-Encoding Fixes It

Every developer has hit the moment where a perfectly formed URL — one that looked right in the browser bar — turned into a server-side mess. The query parameter that contained a user's search phrase arrived on the backend with spaces missing, ampersands chopped, and accented characters mangled beyond recognition. This is not a framework bug or a server misconfiguration. It is the fundamental tension between the characters that are legal in a URL and the characters that humans actually want to put inside one.

URLs were defined by RFC 3986, and the specification is unambiguous: only a small alphabet of "unreserved" characters — the uppercase and lowercase letters A through Z, digits 0 through 9, and the four symbols hyphen, underscore, period, and tilde — can appear anywhere in a URL without any special treatment. Every other character, including the space, the at-sign, the pound sign, and even the innocuous ampersand, carries a reserved or ambiguous meaning in specific positions. When you need one of those characters as data rather than syntax, you must encode it.

What Percent-Encoding Actually Does

The mechanism is simple: each byte of the character is represented as a percent sign followed by two uppercase hexadecimal digits. The space character is Unicode code point U+0020, which in its UTF-8 byte representation is simply the byte 0x20, so it becomes %20. The at-sign (@) is 0x40, so it becomes %40. For multi-byte characters like the euro sign (€, U+20AC), which encodes as three UTF-8 bytes 0xE2 0x82 0xAC, the result is the three-triplet sequence %E2%82%AC.

This is not optional decoration. When a browser sends a GET request, the network stack reads the URL byte by byte. An unencoded space is not a valid byte in that position according to HTTP, and different servers interpret it in incompatible ways — some treat it as the end of the URL, others silently convert it to a plus sign, and others reject the request outright. Percent-encoding collapses this ambiguity into a single deterministic representation.

Three Encoding Modes — and Why They Are All Necessary

A common source of confusion is that JavaScript exposes three different encoding functions, and picking the wrong one causes subtle bugs that only surface in production. Understanding the distinction is the core skill.

encodeURIComponent is the most aggressive of the three. It encodes everything except the 66 characters in the unreserved set. This means it will encode slashes, colons, question marks, hash signs, and ampersands — every character that has syntactic meaning in a URL. You should use this whenever you are encoding a value that will be placed inside a URL, such as a search query, a username, or a redirect target. If you encode the entire URL with this function, you will destroy its structure because the :// and / separators will become %3A%2F%2F and %2F.

encodeURI takes a more permissive approach. It preserves the characters that give a URL its shape: the colon in https:, the double-slash after it, the forward slashes between path segments, the question mark before the query string, the ampersand between parameters, and the hash before a fragment. This function is designed for encoding a complete URL that you have already assembled correctly. It protects the URL's structure while encoding any unsafe characters that might have sneaked into the path or query.

Form encoding (the application/x-www-form-urlencoded format) is the third mode, and it predates the modern URL specification. When an HTML form is submitted with the GET method, the browser serializes the field values in this format. The critical difference is that spaces are represented as a plus sign (+) rather than %20. On the decoding side, any + must be converted back to a space before running the percent-decode step. This mode is still ubiquitous — virtually every HTML form, every OAuth redirect, and most legacy APIs use it. Mixing up + and %20 in the wrong context will result in literal plus signs appearing in your decoded output.

The Decoding Side — Where Most Bugs Live

Encoding is straightforward; decoding is where applications fail. The most common mistake is double-decoding: a server framework automatically decodes the query string, and then the application code runs its own decode pass on top. If a user's input contained %25 (the encoding of a literal percent sign), the first decode produces %, and the second decode tries to interpret that percent sign as the start of a new sequence — and either fails with an error or misinterprets the next two characters as a hex code. Security-conscious developers have found ways to exploit this behavior to bypass filters by providing double-encoded payloads like %2527 (which decodes to %27 and then to a single quote on the second pass).

Invalid percent sequences are another practical hazard. If a user pastes a URL that contains a lone percent sign that is not followed by two valid hex digits — perhaps they copied a broken link, or the percent sign was part of a Windows file path — the JavaScript decodeURIComponent function throws a URIError. Applications that do not catch this exception will crash visibly. The defensive pattern is always to wrap decode calls in a try/catch and surface a meaningful error message rather than an unhandled exception.

Real-World Scenarios Where This Matters

Query string values that contain user-supplied text are the most common use case. A search query like shoes & bags must become shoes%20%26%20bags before being appended to a URL — the ampersand especially must be encoded, because an unencoded ampersand signals the start of the next parameter to every HTTP parser.

Redirect URLs are another minefield. When you encode a return URL as a query parameter — for example, ?redirect=https://example.com/profile?tab=orders — the inner URL's question mark and ampersand will corrupt the outer URL's query string. The redirect value must be fully encoded with encodeURIComponent so its structural characters become %3F and %26.

API integrations involving OAuth signatures are particularly sensitive. OAuth 1.0a requires that the entire parameter string, including already-percent-encoded values, be encoded a second time for the signature base string. Getting this double-encoding right is non-negotiable — a single missed character will produce a signature mismatch that the API server will reject with a cryptic 401 error.

A Quick Encoding Reference

The characters you will encode most often: space (%20), ampersand (%26), equals sign (%3D), hash (%23), plus (%2B), slash (%2F), colon (%3A), at-sign (%40), question mark (%3F), and the double-quote (%22). Non-ASCII characters require converting to UTF-8 bytes first, then encoding each byte — which is exactly what encodeURIComponent handles automatically in JavaScript, sparing you from manual byte arithmetic.

The URL Encoder / Decoder tool on this page handles all three modes with correct JavaScript semantics. Paste your value, choose the mode that matches your context, and click Encode or Decode. The result is immediately available to copy — no server round-trip, no logging of your data, no dependencies. Percent-encoding is deterministic; the same input will always produce the same output, so you can verify the result against any reference implementation and trust what you see.