Paste the URL your app sends users to, or the URL they come back on. The debugger lists every parameter, decoded, and checks the request against RFC 6749, the OAuth 2.0 Security Best Current Practice (RFC 9700), PKCE (RFC 7636) and OpenID Connect. Each finding names the section it comes from. Nothing is sent to a server.
What it checks
The checks only look at the URL. They cannot tell whether a client_id exists or a redirect URI is registered; only the authorization server knows that.
| Check | Rule | Source |
|---|---|---|
| Repeated parameters | Request and response parameters must not appear more than once | RFC 6749 §3.1 |
| response_type=token | Clients should not use response types that put access tokens in the redirect | RFC 9700 §2.1.2 |
| PKCE present | Required for public clients, recommended for confidential clients | RFC 9700 §2.1.1 |
| PKCE method | Use S256; plain only if S256 is technically impossible | RFC 7636 §4.2 |
| state | CSRF protection, unless the client relies on PKCE for it | RFC 9700 §2.1 |
| redirect_uri | Absolute, no fragment, https except loopback | RFC 6749 §3.1.2, RFC 8252 §7.3 |
| nonce | Required when response_type includes id_token | OpenID Connect Core §3.2.2.1 |
| Callback error | Explains the standard error codes | RFC 6749 §4.1.2.1 |
Generating a PKCE pair
The PKCE generator creates a 43-character code_verifier from 32 random bytes and its S256 code_challenge, computed as BASE64URL(SHA256(verifier)) with the browser's Web Crypto API. Use it to test an authorization server by hand. In production your app must create a new verifier for every authorization request; see PKCE explained for code in several languages.