Fix double-encoded query parameters

Problem

Many callback URLs and webhook URLs are encoded more than once during proxying. When `%` becomes `%25`, some systems treat the value as literal text, and you get malformed links, signature mismatches, or hidden tracking values that look correct at first glance.

When to use this

• An OAuth redirect URL returns an invalid_request or callback error.
• A webhook endpoint receives encoded payload values with `%2520`, `%253A`, or `%257B` patterns.
• Analytics/tracker parameters break because one layer is decoded too late or too early.
• You need to compare an original URL against one cleanly decoded variant before testing.

Steps

1. Step 1

   Capture the full raw URL

   Copy the complete URL from the browser, logs, or callback payload. Do not trim at `?` or `&`; both sides of the query must stay intact.

2. Step 2

   Check key shape first

   Open `URL Parser` to inspect query parameter keys and confirm which parameter actually carries the nested value (for example `state`, `redirect`, `returnUrl`, or `callback`).

3. Step 3

   Decode in one controlled step

   Run one decode pass and verify nested values. If `%2520` becomes `%20` but still fails in the receiving system, a second decode may be required—but only for the nested value.

4. Step 4

   Re-encode only at the end

   After you confirm a valid URL, encode once before returning it to app config, callback allowlists, or redirect registration.

Example

https://app.example.com/callback?state=%257B%2522next%2522%253A%2522https%253A%252F%252Fclient.example.com%252Fpost-login%253Futm%253Dsource%2520campaign%2522%257D

https://app.example.com/callback?state={"next":"https://client.example.com/post-login?utm=source campaign"}

Common mistakes

FAQ