go-supertools
Security & Privacy Tools

PKCE Code Verifier & Challenge Generator

Generate a PKCE code verifier and its S256 code challenge for OAuth 2.0.

Runs in your browser Your input never leaves your device.

Code challenge (send this with the authorization request)
code_challenge_method
Authorization request parameters

Verifiers are random, made in your browser with a cryptographic generator, and never sent anywhere. Send the challenge in the authorization request and the verifier only in the token request.

Report a problem with this tool

About this tool

PKCE (Proof Key for Code Exchange, RFC 7636) protects the OAuth 2.0 authorization code flow for apps that cannot keep a secret, such as single-page apps and mobile apps. Your app makes a random code verifier, sends only its hash (the code challenge) in the authorization request, and sends the verifier itself when it exchanges the code for tokens, so a stolen authorization code is useless on its own. This tool generates a verifier of 43 to 128 characters from the allowed alphabet using the browser's cryptographic random generator without bias, and computes the S256 challenge: the base64url encoding of the SHA-256 hash of the verifier, without padding. You can also paste your own verifier to get its challenge, which is handy for debugging a failing flow, and copy the ready-made query parameters. Plain mode, which sends the verifier itself as the challenge, exists in the specification but should only be used when S256 is not possible. The output was checked against the example in RFC 7636 appendix B and against Python. Nothing is sent anywhere.

How to use it

  1. Choose a length (64 is a good default) and press Generate, or paste your own verifier.
  2. Keep S256 as the method.
  3. Copy the code_challenge into the authorization request.
  4. Send the verifier only in the token request, and use a new one for every login.

Common problems

The server says the code verifier is invalid
The challenge you sent must be the S256 of exactly the verifier you send later. Make sure you did not change it, and that the verifier uses only letters, digits and - . _ ~.
Why S256 and not plain?
With plain, an attacker who sees the authorization request learns the verifier. S256 sends only a hash.
Do I need a new verifier each time?
Yes. Generate a fresh random verifier for every authorization request.