Developer / OAuth

PKCE Code Verifier and Challenge Generator

Generate an OAuth 2.0 PKCE code verifier, its S256 code challenge, and a state value, or check a verifier you already have, following RFC 7636.

PKCE Code Verifier and Challenge Generator: PKCE protects the OAuth authorisation code flow for apps that cannot keep a secret, such as mobile and single-page apps. The verifier is a random string of unreserved characters, drawn here from your browser's secure random generator without bias; the challenge is the Base64url-encoded SHA-256 of the verifier. The calculation matches RFC 7636's worked example. Runs 100% locally in your browser with zero server file uploads.

Category
Developer tools
Runs
In your browser
Cost
Free · no sign-up
Availability
Ready to use
PKCE code verifier and challenge generatorLocal processing

Runs entirely in your browser

code_verifier—
code_challenge (S256)—
code_challenge_methodS256
state—

Send code_challenge and code_challenge_method=S256 with the authorisation request, keep the verifier secret on the client, and send it with the token request. The challenge is the Base64url SHA-256 of the verifier, as RFC 7636 defines.

The flow in short

The app makes a verifier and keeps it, sends the challenge to the authorisation server with the sign-in request, receives an authorisation code, then exchanges the code together with the verifier for tokens. An attacker who intercepts the code cannot use it without the verifier.

To inspect the tokens you get back, use the JWT decoder.

Required everywhere now

OAuth 2.1 and current security best practice recommend PKCE for every client using the authorisation code flow, including confidential server-side clients.

How to use it

  1. Choose the verifier length, 43 to 128 characters, and press Generate.
  2. Copy the code challenge and method into the authorisation request.
  3. Keep the verifier for the token request; paste a verifier to see its challenge.

Privacy & limitations

Values are made in your browser and never sent anywhere.

Related tools

JWT DecoderTOTPHMAC

Frequently asked questions

Should I use plain or S256?

Always S256 when the client can compute SHA-256, which every modern platform can; plain exists only for clients that cannot.

What is the state value for?

It protects against cross-site request forgery: send it with the authorisation request and check that the same value comes back.

How long should the verifier be?

At least 43 characters; 64 or more is common. Longer adds randomness but no compatibility problems up to 128.

Free tool · runs in your browser · no account required