Create a cryptographically random PKCE code_verifier and its S256 code_challenge with the Web Crypto API, exactly as RFC 7636 specifies. Build a ready authorization URL and token request for testing, or check that an existing verifier and challenge belong together.
Last updated:
SHA-256 → Base64URL
Authorization URL & token request builder
1. Authorization request (open in the browser)
2. Token request (replace AUTHORIZATION_CODE)
Verify a pair
Advertisement
Advertisement
How to use the PKCE Code Challenge Generator
Click Generate New Pair (a pair is ready when the page loads). Adjust the verifier length if needed.
Copy the code_challenge and send it with code_challenge_method=S256 in the authorization request, or use the URL builder.
Store the code_verifier securely in your app (memory or session storage) until the user returns with an authorization code.
Exchange the code: send the code_verifier in the token request (see the curl example).
Debugging? Paste a verifier and a challenge into Verify a pair to see whether they match.
How the PKCE flow works
Create the verifier. The client generates a high-entropy random code_verifier (43-128 characters from A-Z a-z 0-9 - . _ ~) and keeps it secret.
Derive the challenge.code_challenge = BASE64URL(SHA256(code_verifier)), Base64URL without = padding.
Authorization request. The client redirects the user to the authorization server with code_challenge and code_challenge_method=S256. The server stores the challenge with the authorization code it issues.
Token request. The client sends the authorization code together with the original code_verifier.
Check. The server hashes the verifier and compares it with the stored challenge. Only the client that started the flow can complete it.
Test vector from RFC 7636 (Appendix B)
code_verifier
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
code_challenge (S256)
E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
Click Load RFC 7636 Example to reproduce it with this tool. If your own code gives a different result, the usual culprits are standard Base64 instead of Base64URL, leftover = padding, hashing the hex string of the digest, or hashing a string that contains a trailing newline.
PKCE (Proof Key for Code Exchange, pronounced "pixy") is an OAuth 2.0 extension defined in RFC 7636. The client creates a secret code_verifier, sends only its hash (the code_challenge) with the authorization request, and later proves it started the flow by sending the verifier with the token request. An attacker who intercepts the authorization code cannot use it without the verifier.
How is the S256 code challenge calculated?
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))). The SHA-256 digest of the verifier's ASCII bytes is Base64URL encoded: + becomes -, / becomes _, and the trailing = padding is removed. A SHA-256 challenge is therefore always 43 characters long.
What are the rules for a code_verifier?
It must be 43 to 128 characters long and use only the unreserved characters A-Z, a-z, 0-9, hyphen, period, underscore and tilde. RFC 7636 recommends generating 32 random bytes and Base64URL encoding them, which gives a 43-character verifier with 256 bits of entropy.
Should I use S256 or plain?
Always use S256 when the client can compute SHA-256, which every modern platform can. With plain, the challenge equals the verifier, so anyone who sees the authorization request also learns the verifier. OAuth 2.1 and many providers require S256.
Do I still need a state parameter with PKCE?
PKCE protects against authorization code interception and also prevents CSRF when the server enforces it, but many providers and libraries still expect a state value, and it is useful for carrying app context. Using both is the common recommendation.
Is PKCE only for mobile and single-page apps?
No. PKCE was designed for public clients such as mobile and browser apps that cannot keep a client secret, but the OAuth 2.0 Security Best Current Practice (RFC 9700) recommends it for confidential server-side clients too, and OAuth 2.1 makes it required for the authorization code flow.
Is it safe to generate a code_verifier on a website?
This page creates values locally with the browser's cryptographic random generator and never transmits them. For production, though, your application should generate a fresh verifier for every login; use this tool for learning, testing and debugging.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.