PKCE code verifier and S256 challenge generator
Generate an RFC 7636-compliant code_verifier and its code_challenge, or paste an existing verifier to check it. Everything runs in your browser — no signup, no request, nothing uploaded.
Generated in your browser with crypto.getRandomValues over the 66 unreserved characters, using rejection sampling so every character is uniformly distributed. Nothing is sent anywhere.
—
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) — RFC 7636 §4.2. Send this on /authorize.
S256
OAuth 2.1 removes the plain method. Never send plain to a server that accepts S256.
Paste a challenge to check it against the verifier above. This is the comparison the authorization server performs at the token endpoint.
Running self-test…
This page derives the challenge for the official test vector in the specification and compares it to the published result, in your browser, every time you load it. Verify it yourself:
- code_verifier
- dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
- expected code_challenge
- E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
Using these values in a flow
Send the challenge on the authorization request, then the verifier on the token request. The authorization server hashes the verifier and compares it to the challenge it stored.
GET /authorize ?response_type=code &client_id=YOUR_CLIENT_ID &redirect_uri=https://app.example.in/callback &scope=openid+profile &state=RANDOM_STATE &code_challenge=CHALLENGE &code_challenge_method=S256 POST /token grant_type=authorization_code &code=AUTHORIZATION_CODE &redirect_uri=https://app.example.in/callback &client_id=YOUR_CLIENT_ID &code_verifier=VERIFIER
Store the verifier where it survives the redirect but is not readable by other origins. The backend-for-frontend pattern keeps it server-side; a browser-only client has to accept a weaker storage boundary.
Common questions
- What is a PKCE code verifier?
- A code verifier is a high-entropy random string between 43 and 128 characters, drawn from A-Z, a-z, 0-9 and the characters - . _ ~. Your client generates one per authorization request, keeps it in memory, and sends only its SHA-256 hash to the authorization endpoint.
- How is the S256 code challenge calculated?
- code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))), as defined in RFC 7636 §4.2. The base64url output has no padding, and uses - and _ in place of + and /.
- Why does my token request fail with invalid_grant?
- Most often the verifier sent to the token endpoint does not hash to the challenge sent to the authorization endpoint. Common causes are standard base64 instead of base64url, padding characters left on the challenge, or the client regenerating the verifier between the two requests instead of storing it.
- Should I ever use the plain method?
- No. OAuth 2.1 removes the plain code challenge method. Use S256 everywhere. Sending plain to a server that supports S256 discards the protection PKCE exists to provide.