Developer tools · URL encoder & decoder
Encoding a redirect URL inside a query parameter without breaking it
· How it works
url-encoding query-parameters security oauth
Nesting one URL inside another is the most common place percent-encoding goes wrong. This post shows why the inner URL's ?, & and = must be encoded, how to do it, and how to check the result.
The return-to link that dropped half its parameters — an inner URL's & swallowed by the outer query string
The return-to link that dropped half its parameters is a debugging pattern every developer encounters. A user logs in, the application tries to redirect to ?next=https://example.com/page?id=1&user=alice, and they end up at example.com/page?id=1. The ampersand in the inner URL was parsed as a separator between outer query parameters. Two URLs with different delimiters means the inner one must be encoded.
When nesting one URL inside another as a query parameter, that inner address becomes opaque data to the outer layer. The question mark, ampersand and equals sign must not be readable as structural delimiters. Percent-encoding transforms them: ? becomes %3F, & becomes %26, = becomes %3D. The outer parser then treats the encoded string as one parameter value.
Two URLs, two sets of delimiters — why the inner URL is just a value to the outer one
encodeURIComponent on the complete inner URL produces full protection: encodeURIComponent("https://example.com/a?b=1&c=2") returns "https%3A%2F%2Fexample.com%2Fa%3Fb%3D1%26c%3D2". Every structural character becomes %XX notation so the outer parser cannot misinterpret nested delimiters. A competing approach like encodeURI leaves slashes and question marks untouched, reintroducing ambiguity when that result becomes a query value.
The server decodes exactly once. After extracting the next parameter, a single decodeURIComponent call restores the inner URL to its original form. Parsing the result as a new query string then sees the correct parameter structure. Double-decoding is a risk when the same value passes through multiple layers; %26 becomes & after one decode and stays & after the second.
encodeURIComponent on the whole inner URL — what gets encoded, including :, / and ?
The basic rule is simple: any character that has meaning in URL syntax, including : / ? = & #, must be percent-encoded when it appears in a query parameter value. This ensures the outer parser only sees the parameter structure you intended and not any accidental delimiters hidden inside the value you are passing. Use encodeURIComponent to handle this encoding completely and reliably.
Test this encoding in URL encoder & decoder: paste the inner URL, encode it in value mode, observe the %XX output. Use decoder mode to verify the round trip matches exactly. This tool demonstrates encoding end to end so you can copy the results directly into your application code with confidence.
Worked example: building ?next=https://example.com/a?b=1&c=2 correctly — the encoded string and the decode on the server side
A critical security boundary sits alongside encoding. The server must validate that the decoded destination is actually safe to redirect to. Percent-encoding makes URL structure unambiguous; it does not make arbitrary URLs safe. Open-redirect vulnerabilities happen when applications blindly follow user-supplied URLs. Validation requires an explicit allowlist, domain verification, or user confirmation.
Encoding fixes the parsing problem; validation fixes the security problem. These are separate concerns at different layers. URL encoder & decoder demonstrates encoding correctly. A server must add validation: check against a list, verify the domain, or ask for confirmation. Without validation, a properly encoded redirect to any domain remains exploitable.
Open-redirect risk — why the server must validate the decoded destination, not just decode it
Common mistakes accumulate here. Developers sometimes encode only the query portion, leaving slashes untouched, which breaks structure. Others encode the entire constructed parameter including ?next=, creating double-encoding. Some check validity by parsing without decoding, misreading the encoded structure. Building with encodeURIComponent ensures consistency and correctness in every case.
Another common mistake is trusting the browser to fix a malformed parameter automatically. URLs are data and must be treated precisely as data. encodeURIComponent is the standard tool for this job. URL encoder & decoder keeps this process local so you can verify the exact bytes before shipping to production.
Common mistakes — encoding only the query part, or trusting the browser to fix it
OAuth redirect_uri parameters follow this same pattern exactly. The authorization server passes control to a client at a known address, often a complete URL with multiple parameters. Encoding it as a single value ensures parameters survive transport, and the client decodes once before use. Mishandled encoding in OAuth flows causes tokens and callback parameters to vanish mid-transmission.
State parameters in OAuth use encoding combined with cryptographic signatures for CSRF protection. Fragment identifiers stay on the client side and never travel to the server. Bearer tokens must never be placed in redirect URLs regardless of encoding, because URLs appear in logs, browser history and referrer headers.
What this does not cover — OAuth state parameters and CSRF protection design
Testing strategy: construct your inner URL with real parameters, encode it as an outer value, decode it in receiving code. Verify the decoded result is byte-for-byte identical to the original. Use URL encoder & decoder before production deployment. Examine Network traffic and logs to confirm correct arrival and no truncation or mangling of the encoded data.
A typo like %2e instead of %2E might decode correctly but fail round-trip checks in secondary systems that expect consistency. Encoding mismatches between libraries across different platforms are rare but possible; testing the complete round trip catches them before they cause production issues and customer complaints.
Takeaway: treat the inner URL as data — how the URL encoder & decoder's single-value mode encodes it completely and its decoder confirms the round trip
The encoding boundary is clear: encodeURIComponent treats your input as opaque data and escapes every character except unreserved punctuation, making it safe to nest in any URL layer. The validation boundary is separate: after decoding, verify the destination is where the user intended to go. Use URL encoder & decoder to see encoding demonstrated end to end.
Treat the inner URL as data from the start. Encode it as a single query value, decode exactly once when received, then apply validation before redirecting. URL encoder & decoder shows percent-encoding of any complete URL as a single query value and verifies round trips locally. Both encoding and validation are essential; this tool handles encoding correctly.