Test an OAuth flow by hand
Build an authorization URL for Google, Microsoft Entra ID, Okta or Keycloak, sign in in the browser, then exchange the code with curl by sending the generated code_verifier.
Security & privacy
OAuth PKCE Generator
Create a random code_verifier of 43 to 128 characters and its S256 code_challenge (RFC 7636), or compute the challenge of an existing verifier, with a random state and the parameters to add to the authorization request.
- Clipboard
Leave empty to generate one, or paste an existing verifier to compute its challenge.
PKCE values
Keep it on the client and send it when exchanging the code for a token.
Base64URL of the SHA-256 of the verifier, sent in the authorization request.
Random value to check on return to block CSRF attacks.
Was this tool useful?
How does this tool work?
The OAuth PKCE generator produces the code_verifier / code_challenge pair required by the Authorization Code flow with PKCE, along with a state parameter. It is for developers adding OAuth 2.0 or OpenID Connect login to a SPA, a mobile app or a command-line tool, and for anyone testing the flow by hand with curl or Postman.
PKCE (Proof Key for Code Exchange, RFC 7636) protects the authorization code against interception. The client creates a secret code_verifier of 43 to 128 characters from the unreserved set A–Z, a–z, 0–9, "-", ".", "_" and "~"; the tool generates 64 by default with crypto.getRandomValues. It then computes code_challenge = BASE64URL(SHA-256(code_verifier)), without padding. With the example from RFC appendix B, the verifier dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk gives the challenge E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM.
The challenge goes in the authorization request with code_challenge_method=S256 and a random state; the verifier stays with the client. When exchanging the code for a token, the client sends code_verifier to the token endpoint and the server recomputes the SHA-256 to check that it matches the challenge it received. An attacker who intercepts the code therefore cannot redeem it without the verifier. The tool shows the code_challenge, code_challenge_method and state parameters to add to the authorization URL, and can also recompute the challenge of a verifier you paste to check your own implementation.
How to use this tool
Generate or paste a verifier
Pick a length from 43 to 128 characters (64 by default) to generate a code_verifier, or paste an existing verifier to compute its challenge.
Get the challenge and state
Copy the S256 code_challenge and the random state, checking the displayed verifier and challenge lengths (43 characters for a SHA-256).
Complete the authorization request
Add code_challenge, code_challenge_method=S256 and state to the authorization URL, then keep the verifier to send when exchanging the code.
Use cases
Debug an invalid_grant error
Your server returns "PKCE verification failed": paste the verifier your app used to check that the challenge it sends really is the Base64URL SHA-256, without = or + and / characters.
Set up a Postman or Insomnia client
Generate a verifier / challenge pair and a state to fill in an HTTP client manually when it does not handle PKCE automatically.
Tips and best practices
- Generate a new verifier and a new state for every login attempt: reusing a fixed pair defeats the purpose of PKCE.
- Do not use the plain method: RFC 7636 reserves plain for clients that cannot compute SHA-256, which no current browser or mobile platform lacks.
- In a SPA, keep the verifier in sessionStorage for the duration of the redirect rather than in persistent browser storage, and delete it as soon as the code has been exchanged.
Frequently asked questions
What is PKCE in OAuth?
PKCE (RFC 7636) is an extension of the Authorization Code flow: when exchanging the code, the client proves it is the one that started the request. It first sends a code_challenge derived from a secret, then the secret itself (code_verifier). An intercepted code is useless without that secret.
How long should the code_verifier be?
Between 43 and 128 characters, using only A–Z, a–z, 0–9 and "- . _ ~". RFC 7636 recommends generating it from at least 32 random bytes, which gives 43 Base64URL characters. A 64-character value leaves a comfortable margin.
Should I use S256 or plain?
S256. With plain, the challenge equals the verifier, so anyone who sees the authorization request also knows the secret. Servers that support PKCE must accept S256, and plain only exists for legacy cases.
Is the state parameter still needed with PKCE?
RFC 9700 accepts that PKCE protects against CSRF when the server actually enforces it, but state is still recommended to tie the response to the user’s session and carry application context. Many providers still require it. That is why the tool generates both.
Is PKCE required for confidential clients?
RFC 9700 (OAuth 2.0 Security Best Current Practice, 2025) requires PKCE for public clients and recommends it for confidential clients; the OAuth 2.1 draft makes it mandatory for every client using the authorization code. In practice, enable it everywhere, including server-side apps with a client_secret.
Why is my code_challenge rejected?
Typical mistakes are a challenge encoded in standard Base64 (with +, / or =) instead of Base64URL, a hash computed over a hex version of the SHA-256, or a different verifier between the authorization request and the code exchange. Paste your verifier into the tool to compare with the expected challenge, computed locally with no network request.
Related tools
Keep going with these tools
Tools similar or complementary to this one.
Works well with
Generate secure random tokens from 8 to 256 bytes in hex, Base64 or Base64URL, with an optional prefix.
Security & privacyNewUse this tool
Inspect a JWK or JWKS: kid, kty, alg, use, RFC 7638 thumbprint and a warning when private key material is exposed.
Security & privacyNewUse this tool
Verify a JWT signature with an HMAC secret or a JWK, JWKS or PEM public key, then check exp, nbf, iss and aud.
Security & privacyUse this tool
Read next
GuideBest practicesIntermediate
OAuth 2.0, PKCE, JWT, JWK and JWKS: understand their roles
Understand how OAuth 2.0, PKCE, JWT, JWK and JWKS fit together: authorization, tokens, public keys and verification.
23 September 20262 min
GuideBest practicesBeginner
Web security: understand the essential protections of a website
Understand the layers that protect a website: HTTPS, HTTP security headers, CSP, SRI, authentication, passwords and integrity.
29 August 20262 min
TutorialBest practicesBeginner
How to securely redact a PDF before sharing it
Learn why covering text is not enough, how secure PDF redaction removes sensitive information and why sanitization matters before sharing.
10 September 20262 min
GuideBest practicesBeginner
Content Security Policy (CSP): reduce XSS risks and unwanted loads
Learn how to introduce a CSP progressively, understand its main directives, Report-Only mode, nonces and common mistakes.
29 August 20261 min