OAuth2 Redirect URI Tester
Build authorization requests, test redirect URIs, and inspect callback parameters
The authorization server redirected back with the following parameters.
Parsed Parameters
Decoded Token
Validation Results
Understanding OAuth2 Redirects
How redirect URIs work in OAuth2 and OpenID Connect flows
Redirect URIs
The redirect URI is where the authorization server sends the user after granting (or denying) permission. It must exactly match a URI registered with the OAuth2 provider — no wildcards, no partial matches.
Response Modes
Authorization Code flow returns a code in the query string. Implicit and Hybrid flows return tokens in the URL fragment (#), which never reaches the server — only the browser can read it.
State & PKCE
The state parameter prevents CSRF by binding the request to the session. PKCE adds another layer by proving the client that started the flow is the same one exchanging the code.
Why redirect URI matching is strict
Exact string comparison, by design
The OAuth2 spec requires the redirect URI to be compared as an exact string against a registered value — no normalization, no canonicalization, no treating equivalent URLs as equal. That's why a trailing slash or a default port breaks the match even though both forms address the same resource.
The strictness is deliberate. The redirect URI determines where authorization codes are delivered. Any flexibility in matching is somewhere an attacker can smuggle a redirect to a destination they control, turning a login into an account takeover.
The differences that actually bite
A trailing slash. http versus https. A port that's present, absent, or different — http://localhost and http://localhost:80 are different strings even though 80 is the default. localhost versus 127.0.0.1. Case in the path, which unlike scheme and host is case-sensitive per RFC 3986.
Also: query parameters, which many providers reject outright; fragments, which are forbidden and never reach the server anyway; and double percent-encoding, where %3A becomes %253A after two encoding passes and the server decodes to a mangled string.
Wildcards and preview deployments
Most providers don't support wildcard redirect URIs, and those that do restrict them to a single subdomain level and never in the path. The reason is that a wildcard delegates trust to everything matching it, so one compromised subdomain becomes an account takeover across the whole domain.
This makes per-branch preview deployments awkward, since each gets a fresh generated hostname. The workable options are a stable alias domain for previews that you register once, or a separate application registration for the preview environment.
Frequently asked questions
Redirect URI mismatches, permanently
Wildcards, exact matching, and per-environment callbacks are configurable per application — so staging and production stop fighting each other.
Free, unlimited users. No credit card required.