PKCE Code Verifier & Challenge Generator

Generate an OAuth 2.0 PKCE code_verifier and its matching code_challenge — the two values behind Proof Key for Code Exchange (RFC 7636), the mechanism that stops an intercepted authorization code from being redeemed by an attacker. Set a verifier length, pick S256 or plain, and get a fresh, cryptographically random pair generated entirely in your browser.

What is PKCE, and why two values?

PKCE adds a secret to the OAuth Authorization Code flow so an intercepted authorization code is useless without it:

1. Your client generates a random code_verifier and keeps it secret.
2. It derives a code_challenge from the verifier — base64url(SHA-256(code_verifier)) for S256 — and sends only the challenge in the authorization request.
3. After the user approves and the provider redirects back with a code, your client sends the original code_verifier (never the challenge) to the token endpoint.
4. The server re-derives the challenge from the verifier it just received and checks it matches step 2. A stolen authorization code is worthless without the verifier that produced its challenge.

OAuth 2.1 requires PKCE for every client type — public (SPA, mobile, CLI) and confidential (server-side) alike — not just clients without a client secret.

How to use it

1. Set Verifier Length — 43 to 128 characters (RFC 7636's allowed range). Longer means more entropy; 64 is a reasonable default.
2. Pick a Challenge Method — S256 (SHA-256, base64url-encoded) unless testing the legacy plain method, where the challenge is just the verifier itself. OAuth 2.1 and every modern provider require S256.
3. Choose a Verifier Charset — the full RFC 7636 unreserved set (letters, digits, -, ., _, ~) or the narrower base64url alphabet some libraries default to. Both are spec-compliant.
4. Optionally paste a Code Verifier override to get a reproducible code_challenge instead of a fresh random one — useful for testing against a known value. Leave it blank to generate a new random verifier each time.
5. Click Generate. Send code_challenge + code_challenge_method on the /authorize request, and code_verifier — never the challenge — on the /token request.

code_challenge/code_challenge_method aren't secret; code_verifier is — hold it in memory or sessionStorage for the redirect's duration, send it once, then discard it. Never in localStorage, never logged, never in a URL.

Building a full authorization URL rather than just the PKCE pair? See the OAuth Authorization URL Builder, which bakes an optional PKCE challenge, state, and nonce into a complete redirect URL.

Frequently asked questions

Why is my code_verifier rejected as "invalid"? Check its length (43-128 characters) and character set (only A-Z, a-z, 0-9, -, ., _, ~ — no +, /, or =, which is why it isn't standard base64). Anything outside those bounds violates RFC 7636 §4.1.

Can I reuse the same code_verifier across logins? Don't — treat each authorization attempt as needing its own fresh, unpredictable verifier, the same way you wouldn't reuse a password reset token. Generating a new one is free.

Is there ever a reason to use plain instead of S256? Only for interoperability testing against a client that genuinely can't compute SHA-256 — not a realistic constraint today. Every mainstream identity provider rejects or discourages plain; default to S256.

Privacy

Verifier generation uses a cryptographically secure random number generator, and the S256 hash is computed locally — nothing is sent to, logged by, or stored on a server. Refresh the page and the values are gone.