OAuth PKCE Generator
Generate RFC 7636 verifier, S256 challenge and authorization parameters
Optional: also build an authorization URL
Prefer S256: send the challenge to authorization and the original verifier in the token request. The plain method exposes the verifier; use it only when required by the provider.
Generate to see the verifier, challenge, and optional authorization URL.
About this tool
Generate a cryptographically random 43β128-character code_verifier and its S256 or plain code_challenge using browser cryptography. S256 hashes the verifier with SHA-256 and encodes the result as unpadded Base64url; plain uses the verifier itself. Optional endpoint and client fields build an authorization URL for inspection. No authorization request or token exchange is sent. Results are not saved as drafts, and changing fields discards the current result; the actual OAuth client must retain its verifier until code exchange.
Production Snippets
RFC 7636 Appendix B reference pair
text
code_verifier:
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
code_challenge_method: S256
code_challenge:
E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
This is a published reference pair. Generate creates a new random verifier; it does not accept a custom verifier.Frequently Asked Questions
How is the S256 challenge calculated?
BASE64URL(SHA256(ASCII(code_verifier))), with no trailing = padding. The generated verifier uses only letters, digits, hyphen, dot, underscore, and tilde, and its length must be an integer from 43 to 128. Random bytes use rejection sampling before mapping to the character alphabet.
When should I choose plain instead of S256?
Prefer S256. plain sets code_challenge equal to code_verifier and therefore exposes the verifier in the authorization request. Use it only when the provider explicitly requires and supports that method; it is not an automatic security-equivalent fallback.
Where do the verifier and challenge go?
The authorization request carries code_challenge and code_challenge_method. The later token request carries the original code_verifier with the authorization code. Generating a new verifier between those requests will break that exchange; the actual client must preserve the original value.
Does the tool send an authorization request or obtain tokens?
No. It only constructs values and an optional URL. The endpoint must be HTTP(S), without embedded credentials or a fragment. Client ID, redirect URI, scope, and state must match your provider and application; a generated URL does not prove they are registered or accepted.
How are existing endpoint query parameters handled?
Unrelated query parameters are preserved. response_type is set to code, and the PKCE fields are replaced. client_id, redirect_uri, scope, and state use the corresponding input values; leaving one blank removes an existing value for that parameter. State is not generated automatically.
Are generated values saved, and what happens when I edit a field?
No draft is stored and generation does not upload the verifier. Editing or clearing invalidates any pending hash and removes the old result, so the displayed method, challenge, and URL cannot silently refer to different inputs. Copy values only into your own controlled test client.
Keep browsing