PKCE Challenge Generator
Generate OAuth 2.0 PKCE code_verifier and code_challenge (S256/plain) pairs in-browser. RFC 7636 compliant, Web Crypto API powered, 100% client-side.
Loading tool...
What is PKCE Challenge Generator?
A PKCE Challenge Generator that creates RFC 7636 compliant code_verifier and code_challenge pairs for OAuth 2.0 authorization flows. Supports both S256 (SHA-256) and plain challenge methods, with adjustable verifier lengths from 43 to 128 characters. Everything runs entirely in-browser via the Web Crypto API.
Key Benefits
- Prevents authorization code interception attacks
- Required for public clients like SPAs and mobile apps
- S256 method never exposes the code_verifier in requests
- CSPRNG-quality randomness via crypto.getRandomValues
- No data leaves the browser — 100% client-side
Common Use Cases
- •Securing OAuth 2.0 authorization code flows in SPAs
- •Mobile app authentication with public clients
- •Testing PKCE-enabled identity providers during development
- •Generating PKCE pairs for API integration testing
How to Use the PKCE Challenge Generator
- Select challenge method: Choose S256 (recommended, SHA-256 hash) or plain (verifier as-is).
- Set verifier length: Use the slider or number input to pick 43-128 characters per RFC 7636.
- Generate or paste: Click Regenerate for a new pair, or paste your own code_verifier to compute its S256 challenge.
- Copy and use: Copy code_challenge into your authorization request and code_verifier for the token exchange.
Key Features
- S256 challenge method using SHA-256 hash with Base64URL encoding
- Plain challenge method support for legacy flows
- Adjustable code_verifier length from 43 to 128 characters
- CSPRNG generation via crypto.getRandomValues (no Math.random)
- Paste your own code_verifier with RFC 7636 validation
- One-click copy for both code_verifier and code_challenge
Frequently Asked Questions
What is PKCE?
PKCE (Proof Key for Code Exchange, RFC 7636) is an OAuth 2.0 extension that prevents authorization code interception by requiring the client to prove it holds a secret (code_verifier) when exchanging the authorization code for tokens.
Should I use S256 or plain?
Use S256 whenever possible. It hashes the code_verifier with SHA-256, so the secret never appears in the authorization request. Plain should only be used when the client cannot perform SHA-256.
What characters can a code_verifier contain?
Per RFC 7636, the code_verifier must be 43-128 characters from the set [A-Za-z0-9-._~]. This tool generates from exactly that character set using crypto.getRandomValues.
Is my code_verifier sent anywhere?
No. Everything runs entirely in your browser via the Web Crypto API. No data is sent to any server.