How URL Encoding Works (And Which Encoder You Actually Want)

The bug, first

You want to search for salt & pepper.

Encoded with a whole-URL encoder, the ampersand survives — because a complete URL needs its ampersands. So this arrives at the server:

?q=salt & pepper → a search for "salt ", plus a mystery parameter called " pepper".

Encoded component-safe, it becomes salt%20%26%20pepper and the whole string arrives as one value.

Same input, same intention, two encoders, and only one of them works.

search?q=café latte&sort=new

search%3Fq%3Dcaf%25C3%25A9%2520latte%26sort%3Dnew

search%3Fq%3Dcaf%C3%A9%20latte%26sort%3Dnew

search%253Fq%253Dcaf%2525C3%2525A9%252520latte%2526sort%253Dnew

What percent-encoding is

URLs have a limited alphabet, and some characters carry structural meaning: the slash separates path segments, the question mark starts the query, the ampersand separates parameters.

Percent-encoding replaces anything unsafe or reserved with % followed by its byte value in hex. A space becomes %20, an ampersand %26, a question mark %3F.

It's what lets arbitrary text travel inside a structure that cares about punctuation.

The two encoders

A whole-URL encoder leaves the structural characters alone, because an address needs them to function. A component encoder escapes them too, because a value must not be able to punctuate the URL it's being placed into.

This tool does the component one, deliberately — most encoding happens to values rather than to whole addresses. If you have a complete URL to build, encode each piece and assemble them. Don't run a finished address through a component encoder either, or you'll escape the slashes that make it work.

The output you should actually use

There's a subtlety worth knowing, and the tool shows it rather than hiding it.

The plain encode row escapes your input exactly as given. So if you paste something that's already encoded, its percent signs get escaped again and you get %25 everywhere.

That's the tool being literal, not clever — and it's the same shape as accidental double-encoding, which is why it's shown.

"Decoded, then encoded" is the row to use in practice. It decodes first, so it gives the correct component form whether your input arrived raw or already encoded.

%25 means it was encoded twice

Percent signs are themselves escaped as %25. So running an already-encoded string through an encoder again turns every escape into a longer one:

%20 → %2520

Once you can recognise %2520 as a double-encoded space, this whole class of bug stops being mysterious and becomes obvious on sight. It's one of the highest-value things to be able to spot in a URL.

An empty decode is a diagnosis

A malformed escape — a lone %, or %ZZ which isn't valid hex — cannot be decoded.

The decoder returns an empty string rather than throwing, because an exception inside a page breaks the page instead of reporting the problem.

So an empty decoded output isn't a failure of the tool. It's the tool telling you the input isn't valid percent-encoding, which is usually exactly what you were trying to find out.

Two traps that catch everyone

A + is not a space. In HTML form submissions a space is historically encoded as +, but that's a form-encoding convention and not part of URL percent-encoding. A + here stays a +. If you're decoding something that came out of a form, replace the plus signs with spaces first — a genuinely separate step.

One accented letter becomes two escapes. Percent-encoding works on bytes, and modern URLs use UTF-8 where non-ASCII characters take more than one byte. So é becomes %C3%A9.

That's correct, not a bug — and it's why an encoded string can be dramatically longer than it looks.

Print the encoding reference — the common escapes, plus a checklist for debugging a URL that isn't doing what you meant.