Debugging a Broken Redirect URL: A Developer's Checklist for Encoding Bugs

A link works in your local test, then falls apart in production — truncated query string, a login redirect that lands on the wrong page, or a value that shows up half-decoded. Here's a step-by-step checklist for finding which layer of encoding actually broke.

Why does my redirect break when the parameter is itself a URL?

Quick answerA URL placed inside another URL's query string needs its own encodeURIComponent() pass first. Otherwise its internal ?, &, and = characters get parsed as part of the outer query string, and everything after them gets cut off or misread.

This is one of the most common real-world encoding bugs, and it usually shows up in login flows, checkout redirects, and "share this page" links. Say a login page needs to send the user back to their dashboard afterward, using a parameter named returnUrl:

Broken (example): /login?returnUrl=https://app.example.com/dashboard?tab=billing&ref=email

Here the outer parser sees four separate parameters — returnUrl, tab, ref — because the inner URL's own ? and & were never escaped. The login page only sees returnUrl=https://app.example.com/dashboard and silently drops ?tab=billing&ref=email.

The fix is to encode the entire inner URL with encodeURIComponent() before appending it as a value: /login?returnUrl=https%3A%2F%2Fapp.example.com%2Fdashboard%3Ftab%3Dbilling%26ref%3Demail. Now the outer parser sees exactly one returnUrl parameter, and the receiving code decodes it once to get the original, complete address back.

A five-step checklist for a broken link

When a URL isn't behaving — a parameter is missing, garbled, or the wrong page loads — work through these steps roughly in order:

1. Parse the full URL first. Break it into protocol, host, path, query, and fragment before touching anything else. Sometimes the "missing" parameter is actually sitting inside the fragment (after #), which most servers never see at all — that's a routing issue, not an encoding one.
2. Decode each parameter value once and read it. If it still contains %XX sequences or a literal %25, you're looking at a double-encoded value — decode again (or use a multi-layer/nested decode) to reach the real content.
3. Check for un-escaped structural characters. An inner &, =, or ? that wasn't encoded will fracture the query string into extra parameters you didn't intend, exactly like the returnUrl example above.
4. Confirm which encoding function produced the value. A single-parameter value should come from encodeURIComponent; a whole address from encodeURI. Mixing them up is the single most frequent root cause.
5. Check the userinfo field. If the parsed host shows a username or password before the @, credentials are embedded directly in the link — flag it before you paste that URL into a ticket, log, or chat message.

The "+" vs "%20" trap in form-encoded data

Quick answerInside application/x-www-form-urlencoded data (HTML form submissions), a literal + means a space, and so does %20 — but outside that specific context, + is just a plus sign. Mixing the two conventions produces spaces that silently turn into plus signs, or plus signs that get read as spaces.

This shows up often when a value is copied from a form submission log into a hand-built API request, or vice-versa. A search box that submits via a standard HTML form will often send a space as +; a JSON API endpoint or a manually built query string almost always expects %20 instead. If your debugging tool decodes + as a literal plus sign when the source actually meant "space" (or the reverse), the field will look subtly wrong — often only for multi-word values, which makes it easy to miss in a quick test with single-word data.

Context	Space encodes as	Literal "+" encodes as
encodeURIComponent (JS default)	`%20`	`%2B`
application/x-www-form-urlencoded	`+` (or `%20`)	`%2B`

When testing a suspicious value, try toggling a "form encoding" option in a decode/encode tool and compare both outputs — if one interpretation produces a sensible sentence and the other produces broken words with stray plus signs, you've identified which convention the original data used.

Good to know: a URL parser that separates the hostname into subdomain, domain, and TLD, and the path into directory, filename, and extension, makes it much faster to spot a malformed redirect target — for example, a returnUrl that unexpectedly points to a different domain than expected is easier to catch once the host is broken into parts instead of read as one long string.

Paste a broken URL and see it parsed into every part, decode nested layers in one pass, and test encodeURIComponent vs encodeURI side by side — free and entirely in your browser.

Try the free URL Encode / Decode tool →

Frequently asked questions

Why does my redirect URL break when it contains another URL as a parameter?

A redirect link like ?returnUrl=https://app.example.com/dashboard breaks because the inner URL's own '?', '&', and '=' characters get read as part of the outer query string instead of as part of the value. The inner URL needs to be passed through encodeURIComponent() before being appended as a parameter value, turning its slashes and punctuation into %XX sequences so the outer parser treats the whole thing as one opaque value.

How can I tell if a URL parameter was encoded twice by mistake?

Look for a literal '%25' in the decoded output, or a value that still contains %XX sequences after you've already decoded it once. For example, a parameter that reads name%3DJohn%2520Smith decodes once to name=John%20Smith — the %2520 (double-encoded space) is the giveaway. A URL parser or decoder with a multi-layer/nested option resolves every layer in a single pass so you can see the final, original value.

Why does a plus sign (+) in a query string sometimes turn into a space?

The '+' character has a special meaning specifically inside application/x-www-form-urlencoded data (the format used by HTML form submissions and by encoding libraries in "form mode"): there, '+' represents a space and %20 also represents a space. Outside that context, '+' is just a literal plus sign. This is why a search form and a hand-built API URL can encode the same space two different ways, and mixing the two conventions is a common source of bugs.

How do I check whether a username or password ended up embedded in a URL by accident?

Parse the URL and look at the userinfo section — the part between '://' and '@' in the host, formatted as username:password. If a URL parser shows a non-empty username or password field, credentials are exposed directly in the address, which is unsafe to log, share, or paste into a bug tracker or chat channel, since anyone with the link also gets the credentials.

What's the fastest way to test a query-string builder before shipping it?

Feed it parameter values that are deliberately awkward — a value containing an ampersand, a space, an equals sign, an accented letter, and a full nested URL — and confirm the built query string decodes back to those exact original values with no truncation or corruption. If any single case fails, the builder is encoding at the wrong layer or missing a character class.

Related guides

Methodology note: examples in this guide use illustrative sample URLs, domains, and parameter names for clarity — they are not real production links or credentials. This article is for general informational purposes and is not legal, security, or professional advice; always review your own data-handling and logging policies before sharing or publishing URLs that may contain sensitive information.