Skip to content
100% local

PKCE verifier and challenge generator

Generate a cryptographically random code_verifier and its code_challenge for OAuth 2.0 PKCE.

43
Output

PKCE verifier and challenge generator

This tool generates a PKCE code_verifier and its matching code_challenge for the OAuth 2.0 Authorization Code flow, following RFC 7636. It is built for developers wiring up single-page apps, mobile apps, or any public client that cannot safely hold a client secret and needs Proof Key for Code Exchange to protect the authorization code from interception.

The code_verifier is a cryptographically random string built only from the RFC 3986 unreserved characters (A–Z, a–z, 0–9, "-", ".", "_", "~"), between 43 and 128 characters long — choose the exact length with the slider. The challenge method controls how code_challenge is derived: S256 hashes the verifier with SHA-256 and base64url-encodes the digest, and is what every current OAuth guide and authorization server expects. The plain method just copies the verifier into the challenge unchanged; it exists in the spec for constrained clients that cannot compute SHA-256, offers no protection against interception, and this tool marks it accordingly.

The output includes the raw code_verifier and code_challenge, the method you chose, and a ready-made query string — code_challenge=...&code_challenge_method=... — that you can drop straight into an authorization request URL. Remember the verifier separately: it belongs in the later token request, not the authorization one, and a fresh pair should be generated for every login attempt rather than reused.

All generation happens locally in your browser, using the Web Crypto API's cryptographically secure random source and SHA-256 implementation — nothing is uploaded or logged anywhere. Click "Generate new pair" for a fresh verifier and challenge, copy the output, or download it as a .txt file.

FAQ

What is PKCE and why do I need it?
PKCE (Proof Key for Code Exchange, RFC 7636) protects the OAuth 2.0 Authorization Code flow for clients that cannot keep a secret, like single-page apps and mobile apps. It ties the authorization request to the token request with a random secret so a stolen authorization code cannot be redeemed by someone else.
Should I choose S256 or plain?
Use S256 unless your client genuinely cannot compute SHA-256. With plain, code_challenge equals code_verifier, so an attacker who intercepts the authorization request already has everything needed to exchange the code — S256 is what modern authorization servers expect and often the only method they accept.
Can I reuse the same verifier and challenge for multiple logins?
No. Generate a new pair for every authorization attempt. The verifier is meant to be a one-time secret tied to a single flow, not a fixed value your app hardcodes.
Where do the code_verifier and code_challenge each go?
code_challenge and code_challenge_method go in the initial authorization request URL. code_verifier is sent later, in the token request that exchanges the authorization code for tokens — keep it in memory or session storage on the client until then.
Is the generated verifier uploaded anywhere?
No. Generation runs entirely in your browser using the Web Crypto API. Nothing is sent to a server, logged, or stored beyond your own session.