URL Parser

At least one value still contains a % escape after decoding — it was probably encoded twice. That is the usual cause of a redirect or callback parameter arriving mangled.

encodeURI and encodeURIComponent are not interchangeable

encodeURI leaves / ? & = # alone because it expects a whole URL. Use it on a parameter value and the value's own & silently becomes a parameter separator — which is a parameter injection, not just a display bug.

The fragment never reaches the server

Everything after # is processed by the browser only. It will not appear in your access log, and it cannot be read server-side — which is why OAuth implicit flow tokens placed there are invisible to your backend.

Plus is a space, but only sometimes

In application/x-www-form-urlencoded data, + decodes to a space. In a path segment it is a literal plus. This is why email addresses with a tag arrive broken from some forms.

The host may not be what you read

Userinfo before an @, and Unicode homographs, both make the apparent host differ from the real one. The punycode form below the host is the authoritative answer — if it starts xn--, look closely.

Repeated keys are not an error

?a=1&a=2 is valid, and frameworks disagree on whether you get the first, the last, or an array. Every occurrence is listed above rather than collapsed.