encodeURI vs encodeURIComponent for redirect_uri and Query Params
A practical guide to choosing the right encoding boundary for redirect_uri, nested URLs, and query parameter values before a small encoding mistake turns into a redirect bug.
Many encoding bugs are not caused by the wrong function alone. They are caused by applying the right function to the wrong boundary. A developer sees a failing redirect, reaches for encodeURI or encodeURIComponent, and fixes the symptom in one test case while quietly breaking another surface.
The useful question is not “which function is better?” The useful question is “what exactly am I encoding right now?” Is it a complete URL that should stay readable as a URL, or one nested value that must survive inside another query string as a single safe unit? Once that boundary is clear, the encoding choice becomes much easier and far more consistent.
Treat the whole URL and the nested value as different surfaces
If the string in front of you is already the final URL a browser should read, encodeURI-style behavior usually makes more sense because it preserves separators such as /, ?, &, and =. Those characters are meaningful at the top level of a readable URL.
If the string is going to be inserted into another URL as one value, the situation changes. A nested redirect target must usually be encoded as one component so that its own separators do not escape into the outer query string. This is why redirect_uri=https://app.example.com/callback?from=pricing&utm=ads often breaks unless the redirect target is encoded before attachment.
NoteThe most common production mistake is treating a nested URL as if it were already the final top-level URL.
Use URL Encoder when you need to compare those two boundaries side by side before the wrong one ships.
Tools for this section
Use component encoding for values that must stay together
A query value containing spaces, ampersands, equals signs, or even another URL should usually be encoded as one component before it is added to the outer URL. Otherwise the outer parser can split the value too early and treat part of it as a new key.
Wrong:
/login?redirect_uri=https://app.example.com/callback?from=pricing&utm=ads
Safer:
/login?redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback%3Ffrom%3Dpricing%26utm%3Dads
That second version is not prettier, but it is safer because the nested target survives as one unit. This is the exact moment where encodeURIComponent-style behavior is usually the better fit.
Tools for this section
Stop and check for over-encoding before adding another pass
When a value already contains %3A, %2F, or repeated %25 patterns, another encoding pass may hide the real bug instead of fixing it. This is where teams often make a broken redirect slightly harder to reason about by encoding the same value twice in different layers.
The safer workflow is:
- inspect the current input as-is,
- decide whether it is a whole URL or one component,
- encode exactly once at that boundary,
- then decode once during debugging if you need to verify what the nested value really contains.
If you cannot clearly explain which layer owns the encoding step, you probably are not ready to add another one.
Tools for this section
URL Encoder
Encode a full URL or a single nested component with the right boundary, then copy a clean result for redirects, query parameters, and callback links.
URL Decoder
Decode percent-encoded URL strings back to human-readable plain text.
URL Query Parameter Inspector
Inspect a full URL, decode query values, group duplicate keys, and flag suspicious tracking parameters directly in your browser.