Why Your redirect_uri Breaks: Nested Params, + Signs, and Double Encoding
A practical guide for redirect_uri bugs caused by nested query strings, plus-sign handling, and accidental double encoding across browser and server layers.
Most broken redirect_uri bugs do not start where they finally explode. The visible symptom is usually vague: an OAuth callback suddenly drops the user on the wrong page, a ReturnUrl only fails for a few campaign links, or a redirect that worked yesterday starts truncating everything after the first inner &. Underneath, the same pattern keeps repeating: a nested URL was treated as ordinary text instead of one encoded value, so one layer split or decoded it at the wrong time.
This guide is built around three real classes of failure that developers repeatedly run into: outer query strings swallowing part of an inner redirect target, + signs changing meaning depending on whether the value came from a path or form-style query data, and %252F or %2540 sequences proving that the value was encoded twice somewhere upstream.
Start with the raw nested value, not the whole login URL
The first mistake is trying to reason about the entire login URL at once. A redirect bug almost always becomes clearer when you reduce the problem to one field. By the time your backend reads the request, redirect_uri may contain only half of the URL, while the rest behaves like an unrelated outer parameter.
- Capture the exact browser URL before any framework parsing.
- Extract only
redirect_uri,return_to,next, or the equivalent field. - Decode that single value once in URL Decoder.
- Confirm that its own
?and&still live inside the target.
Decide whether `+` is data or whitespace before you touch it
The second failure mode is subtle. A developer sees + in a failing value and assumes it should obviously become a space. That assumption is only sometimes true. In many form-style query strings, + behaves like whitespace. In a path segment, it often remains a literal plus sign. If you cannot say which surface produced the value, you are still too early in the investigation to normalize it safely.
Use checkpoints to prove where double encoding starts
Once %252F, %2540, or repeated %25 patterns appear, stop guessing and switch to checkpoint-based debugging. Those sequences usually mean the percent sign itself was escaped again, which means the redirect was encoded twice at different stages. Do not add a second decode call just because it makes one failing test pass. Instead, capture the value in three places: the browser URL, the framework-level parameter your server receives, and the exact string used when you build the next redirect.