ndovu oauth2 minisite

PLAYGROUND · RFC 7636

PKCE playground

Generate a real PKCE code verifier and its S256 challenge in your browser with WebCrypto: the exact handshake RFC 7636 expects before an authorize request.

October 24, 2026Read: RFC 6749 primer
01

What you are looking at

PKCE ("pixy"), the Proof Key for Code Exchange, protects the authorization-code grant for clients that cannot keep a secret: SPAs, mobile apps, CLIs. Before sending a user to the authorize endpoint, the client creates a random, high-entropy code verifier and derives a code challenge from it by hashing it with SHA-256. The challenge travels with the authorize request; the verifier stays put until the token exchange, where the authorization server demands it back and checks the hash matches. A stolen authorization code is then worthless without the verifier.

The island below runs the real thing with WebCrypto, in your browser:

Code verifier
43 chars, base64url of 32 random bytes. Keep it secret; send it to the token endpoint.
Code challenge (S256)
43 chars, base64url(SHA-256(verifier)). Send it as code_challenge with code_challenge_method=S256.
Generated in your browser via WebCrypto. Nothing is sent anywhere.
02

Using the pair

  1. Send the user to the authorize endpoint withcode_challenge and code_challenge_method=S256added to the usual parameters (response_type=code,client_id, redirect_uri, scope,state).
  2. At the token exchange, send the code_verifier alongside the code. The server hashes it and compares against the challenge it stored; a mismatch fails the request.
Try this

Hit regenerate a few times: every verifier is 43 characters of base64url, and every challenge is a different 43-character digest of its verifier. Copy a pair and paste them into your own authorize request - they are valid PKCE parameters.