URL Encoder and Decoder

How it works

JavaScript has two pairs of standard URL functions, and the distinction is important. The component pair treats the input as one value. It escapes every character that could be mistaken for URL structure, including the ampersand between parameters, the equals sign between a key and value, and the slash between path segments. This is the right operation before inserting a user value into a query string.

The URI pair treats the input as an address that already has structure. It preserves the characters that identify the scheme, host, path, and query separators while escaping spaces and characters that cannot appear literally. The tool does not guess which mode you intended because that guess is how a valid URL becomes a different request.

Decoding reverses the relevant operation. Invalid escapes are reported by the native function and shown in the interface. That matters when debugging a request copied from a log: silently replacing malformed bytes could make the displayed request differ from what the server actually saw.

When you'd use this

Use component encoding when building a search URL, redirect parameter, callback URL, or test fixture from separate values. A phrase such as red shoes & boots must not contribute an accidental second query parameter. Use complete-URI encoding when a whole address needs to be made safe for transport while keeping its slashes and question mark recognizable.

Use decoding when reading browser history, webhook payloads, server logs, or an API request captured in a debugging tool. The readable value is useful for checking whether a space, Unicode symbol, or reserved punctuation survived a round trip. The output is a transformed string, not a validated or reachable website, so still inspect the destination before opening it.

The tool intentionally does not normalize hosts, validate schemes, or follow links. Encoding and validation are different jobs. Keeping the operation narrow makes the result predictable and avoids turning a string transformer into a network request.

The plus sign is the classic trap

%20 and + both appear as a space in URLs, and they are not interchangeable. This one difference accounts for a large share of the bugs that reach production.

+ for space comes from the application/x-www-form-urlencoded format used by HTML form submissions. It is a form-encoding rule, not a URL rule. In a URL path, + is an ordinary literal plus sign with no special meaning at all.

So a value encoded one way and decoded the other goes wrong in both directions. Encode a+b — say a search for a formula, or a phone number in international format — with component encoding and you get a%2Bb, which is correct and safe. Let it through unencoded and a server treating the query as form data reads it as a b, silently turning a plus into a space.

The reverse is worse and more common: an email address like [email protected]. Those tagged addresses are widely used for filtering, and they break constantly, because the plus survives into a query string and something downstream decodes it as a space. The address becomes user [email protected] and the mail bounces.

The rule that avoids all of it: always percent-encode the value, never rely on +. %2B for a literal plus and %20 for a space are unambiguous everywhere — in paths, in query strings, and in form bodies.

Encoding twice is a real bug, and it is visible

Double encoding happens when a value that is already encoded gets encoded again, and its signature is easy to recognize once you have seen it.

The percent sign is itself a character that needs escaping, so %20 encoded a second time becomes %2520 — the % turned into %25 and the 20 stayed. Any %25 in a URL where you did not intend a literal percent sign means an extra pass happened somewhere.

It usually comes from a value crossing layers, each of which believes it is responsible for encoding: a template helper encodes it, then the HTTP client encodes the whole URL again. The result is a request for a path containing a literal %20 rather than a space, and the server answers 404 for a resource that exists.

Decoding here is the quickest diagnosis. Paste the failing URL, decode once, and look: if the result still contains percent escapes, it was double-encoded. Decode again to see the value that was originally meant.

The fix is to decide which layer owns encoding and remove it from the others. Encoding is not idempotent, so "encode again to be safe" is never safe.