URL Encoder

Why URLs need an escape hatch

A URL is not just a string; it is a structured expression in which certain characters carry meaning. The question mark starts the query string. The ampersand separates one parameter from the next. The equals sign divides a parameter's name from its value. The hash introduces a fragment. The slash separates path segments. Now suppose one of your values legitimately contains an ampersand — a search for 'Marks & Spencer', say. Written literally, the parser sees the ampersand and concludes that a new parameter has begun, and your search term is silently truncated to 'Marks '. Percent-encoding is the escape hatch: it lets you say 'this ampersand is data, not structure' by writing it as %26. Every character that means something to the URL grammar needs this treatment when it appears in a value.

Double encoding, the classic bug

The most common URL-encoding bug is encoding something twice. A space becomes %20 on the first pass. Run that result through an encoder again and the percent sign — which is itself a special character — gets encoded to %25, so %20 becomes %2520. The URL still looks plausible and is now wrong, and the far end receives the literal text '%20' rather than a space. This happens constantly when a value passes through several layers that each helpfully encode it: a framework encodes, then a template helper encodes again, then a redirect encodes a third time. If you see %2520 anywhere in a URL, you are looking at a double-encoded space, and the fix is to find the layer that is encoding something already encoded rather than to decode twice at the far end.