URL Encoder / Decoder

The dangerous thing about URL encoding mistakes is that nothing errors. The request succeeds, the page loads, and the data is simply wrong.

An unencoded ampersand inside a query value splits it into two parameters. An unencoded hash truncates everything after it, because the browser reads it as a fragment and never sends it. Both fail quietly, and you find out weeks later when the campaign report has a column of blanks in it.

What percent-encoding does

It replaces characters that either have structural meaning in a URL — ampersand, equals, question mark, hash, slash — or are simply unsafe there, with a percent sign and their hexadecimal value. A space becomes %20, an ampersand becomes %26.

Encode the values, not the URL

This is the rule that saves the most time. Encode each parameter value you are inserting, not the whole address. Run a complete URL through an encoder and the slashes and colons get escaped too, producing something that looks encoded and resolves to nothing.

The plus sign problem

Inside a query string, a plus historically means a space. Elsewhere in a URL it is literal. That ambiguity is real and it bites hardest with email addresses — an address containing a plus, passed through a query string, frequently arrives with a space in the middle of it. Encode it as %2B when it is data.

Double encoding

Encoding an already-encoded string turns %20 into %2520. The result looks plausible and resolves to nonsense. If a link is behaving strangely, decode it once and see whether you get something readable or another layer of escapes.

One distinction worth keeping straight: this is not HTML escaping. HTML escaping protects markup and produces things like &. Percent-encoding protects URLs. Using one where the other belongs is a common source of broken links.