URL encoding: why spaces become %20

A URL is not free text. The spec reserves certain characters as structure — ? starts the query string, & separates parameters, = assigns values, # jumps to a fragment, / divides paths. If your data contains those characters as data, they must be disguised, or the URL's meaning changes.

The disguise is percent-encoding: the character's byte value in hex, prefixed with %. A space is %20, an ampersand is %26, a question mark is %3F. Non-ASCII characters encode each UTF-8 byte: é becomes %C3%A9. That's the entire mechanism.

Where it bites

The classic bug: building a URL by string concatenation with user input. A search for 'cats & dogs' becomes ?q=cats & dogs, the & splits the parameter, and the server sees q=cats. Encode first (the tool above, or encodeURIComponent in JavaScript) and it becomes ?q=cats%20%26%20dogs — intact.

The second classic: double encoding. Encode twice and %20 becomes %2520, because the % itself got encoded. If you've ever seen %2520 in the wild — and every developer has — that's two layers of encoding fighting. Decode twice to unwrap it, then fix whichever layer shouldn't exist.

And the + confusion: in query strings specifically, an old convention lets + stand for space, but in paths + means literal plus. Our decoder treats + as a space the way query strings do, which is the behavior people expect when debugging.

The practical rules

Encode each parameter value individually, never the whole URL at once (that would break the ?, &, and = doing their jobs). Decode exactly as many times as something was encoded. And when a URL misbehaves, paste it into the decoder above — one pass usually reveals what the string actually says under the percent signs.