URL Encoder and Decoder

What this tool does

This URL encoder and decoder turns text into percent-encoded form and back, with the one choice that actually decides the output made explicit: whether you are encoding a single value that will sit inside a URL, or a whole address that already has its structure.

Get that choice wrong and nothing looks broken. A query parameter encoded as a whole URL keeps its & and =, so the receiving server reads one parameter as three. A whole URL encoded as a component arrives as an unusable string of %3A%2F%2F. Both mistakes ship, because both produce output that looks plausible.

How to use it

1. Pick a direction: encode or decode.
2. When encoding, say whether the input is a value inside a URL or a whole URL.
3. Tick Form encoding if spaces should become + rather than %20.
4. Paste, then copy the result.

Decoding is tolerant. It accepts uppercase or lowercase hex digits, leaves untouched anything that was never escaped, and only refuses a % that is not followed by two hex digits — naming the position, because a lone percent sign in the middle of a long string is otherwise invisible.

encodeURI against encodeURIComponent

The two functions differ in exactly eleven characters: # $ & + , / : ; = ? @. encodeURI keeps them, encodeURIComponent escapes them. Everything else, both treat identically.

That eleven-character difference is the whole decision:

• You built the URL and want it safe to transmit. Use whole-URL mode. Spaces and non-ASCII characters get escaped; the delimiters that make the address parse stay as they are.
• You have a value going into a parameter, a path segment or a fragment. Use component mode. A search term containing &, a redirect URL passed as a parameter, an email address in a path — all of them need their delimiters escaped, or they end the value early.

The second case is the one that bites. ?next=https://example.com/a?b=1 is not one parameter, it is two, and the second server sees b=1 as its own. Encoding the value as a component fixes it.

+ against %20, and why both exist

There are two different specifications in play. Percent-encoding, from RFC 3986, escapes a space as %20 anywhere in a URL. Form encoding, from the HTML specification, defines a media type called application/x-www-form-urlencoded that writes a space as + — a shorthand that predates the URL standard and survives because every HTML form still posts that way.

The rules that follow from that:

• In a path segment, + is a literal plus. Decoding it as a space corrupts filenames.
• In a query string, most server frameworks decode + as a space, because most query strings come from forms. A literal plus therefore has to be sent as %2B.
• %20 is safe in both places. When in doubt, use it.

This is why a search for C++ so often returns results for C with two spaces: someone put the literal plus into a query string without escaping it.

Double encoding, and how to spot it

Double encoding happens when a value is encoded by two layers that both think they own it — a client that escapes before building the URL and a framework that escapes again on the way out. The % of the first pass becomes %25, so %20 becomes %2520 and a space arrives as the literal text %20.

It is easy to detect and hard to notice: decode once, and if the result still contains escape sequences, you have found it. The tool says so when it happens. The repair is never to decode twice in production — that would break any value that legitimately contains a percent sign — but to remove the duplicate encoding step.

Related encodings

Percent-encoding is one of three that developers meet in the same afternoon and confuse with each other. Base64 moves bytes through a text channel and does not care about URL structure at all — though its URL-safe variant exists because standard Base64 contains + and /. HTML entities protect markup, not addresses. A value bound for an href attribute in an HTML page frequently needs both, in that order: percent-encode the value, then escape the resulting string for the attribute.