URLs, encoded
and decoded

A URL has a limited alphabet. Only unreserved characters (letters, digits, and the four marks - . _ ~) may appear literally anywhere. Everything else is either reserved, meaning it carries structural meaning, or simply not allowed.

Percent-encoding is the escape hatch. The character is converted to its UTF-8 bytes, and each byte is written as a percent sign followed by two hexadecimal digits. A space is byte 0x20, so it becomes %20.

The important consequence is that encoding operates on bytes, not characters. Anything outside ASCII produces more than one escape.

Reserved characters are the ones that give a URL its shape: the colon after the scheme, the slashes between path segments, the question mark before the query, the ampersands between parameters, the hash before a fragment.

Whether those should be encoded depends entirely on what you are encoding. That single question is what separates the three modes, and getting it wrong is the most common URL bug there is.

In form encoding, a plus sign means a space. In every other part of a URL, a plus sign means a literal plus sign. The same character, two meanings, decided entirely by context.

This breaks things quietly. An email address like first+tag@example.com survives a normal path unchanged, but decoded as form data it turns into "first tag@example.com" and no longer matches any account.

Encoding an already-encoded string escapes the percent signs themselves, so %20 becomes %2520. Decode that once and you get %20 back rather than a space, which is why a value can arrive looking almost right but not quite.

It happens most often when a value passes through several layers, each helpfully encoding on your behalf: a template helper, an HTTP client, and a proxy might each apply a round.

The signature is easy to spot once you know it. Sequences like %2520, %253A, or %2526 in a URL mean something has been encoded twice.

The built-in functions predate RFC 3986 and do not match it exactly. encodeURIComponent leaves five characters unescaped that the standard treats as reserved: ! ’ ( ) and *.

For most purposes that is harmless. It matters when you are building a signature or a canonical string that another system will verify, since AWS request signing and OAuth 1.0 both expect the stricter set.

Encode values individually, at the point where you place them into a URL. Do not assemble a URL from raw pieces and encode the whole thing at the end, because by then the parser cannot tell your data apart from the structure.

In practice the platform usually does this better than manual string work. URL and URLSearchParams handle the escaping rules, and they get the edge cases right.