PKCE Generator

Generate code_verifier and code_challenge pairs for secure OAuth2 authorization flows

43–128 characters (RFC 7636)
code_verifier
Click generate to create a PKCE pair
code_challenge
—
code_challenge_method
—
Usage in Authorization Request
Generate a pair first to see the example

Understanding PKCE

Why Proof Key for Code Exchange matters for OAuth2 security

What is PKCE?

PKCE (Proof Key for Code Exchange) is an extension to OAuth2 that prevents authorization code interception attacks. It is now recommended for all OAuth2 clients, including server-side applications.

How It Works

The client generates a random code_verifier and derives a code_challenge. The challenge is sent with the authorization request, and the verifier is sent when exchanging the code for tokens.

S256 vs Plain

S256 applies a SHA-256 hash to the verifier, providing protection even if the challenge is intercepted. The plain method sends the verifier as-is and should only be used when S256 is not supported.

PKCE in practice

How the pair is used

Generate a random code_verifier, derive code_challenge = base64url(SHA256(verifier)), and send only the challenge on the authorization request along with code_challenge_method=S256. Keep the verifier in your client.

When you exchange the authorization code for tokens, send the verifier. The server hashes it and compares against the challenge it stored. A match proves the party redeeming the code is the same one that started the flow — so a code intercepted from a redirect URL, a log, or browser history is useless on its own.

Requirements that are easy to violate

The verifier must be 43–128 characters from the unreserved set [A-Z] [a-z] [0-9] - . _ ~. Shorter than 43 is a spec violation and materially weakens the entropy. It must come from a cryptographically secure random source — Math.random() is not one.

Generate a fresh verifier for every authorization request. Reusing one across flows reintroduces exactly the replay problem PKCE exists to close, and makes the challenge predictable for anyone who saw a previous request.

S256 versus plain

The plain method sends the verifier unmodified as the challenge, which means anyone who observes the authorization request has the verifier. It provides no protection and exists only for clients that genuinely cannot compute SHA-256.

Always use S256. If your authorization server accepts plain, check whether it can be disabled — an attacker who can modify the authorization request may be able to downgrade the method and defeat the mechanism entirely.

Frequently asked questions

Yes. A client secret authenticates the application; PKCE authenticates the specific flow. They cover different attacks, and the secret does not protect against code interception. OAuth 2.1 makes PKCE mandatory for all clients using the authorization code flow, confidential ones included.

No — they defend against different things. PKCE binds the authorization code to the client instance. The state parameter protects against cross-site request forgery on the callback. You need both, and they are independent values.

Somewhere scoped to the browsing session and not readable cross-origin — sessionStorage is typical for SPAs, or an httpOnly cookie set by your backend. It only needs to survive the redirect round trip, so it should be cleared as soon as the token exchange completes.

No. Generate a fresh pair per authorization request. Reuse means an attacker who captured an earlier request can predict the challenge and redeem an intercepted code.

Yes — it uses crypto.getRandomValues() from the Web Crypto API, and the SHA-256 hash uses crypto.subtle.digest(). Everything runs in your browser and nothing is transmitted.

Next steps

Related tools

In the docs

All developer tools

PKCE is the easy part

Verifier and challenge are ten lines. Token storage, silent refresh, and rotation are where SPA auth actually gets hard — our SDKs handle all three.

Start free Read the PKCE guide

Free, unlimited users. No credit card required.