PKCE Generator
GeneratorGenerate OAuth 2.0 PKCE code_verifier and code_challenge pairs instantly. RFC 7636 compliant, S256 method, URL-safe random verifier. Runs entirely in your browser.
PKCE (Proof Key for Code Exchange, pronounced 'pixie') is an OAuth 2.0 extension (RFC 7636) that protects public clients against authorization code interception attacks. Before initiating the OAuth flow, the client generates a random secret called the code_verifier, derives a code_challenge from it using SHA-256, and sends the challenge to the authorization server. When exchanging the authorization code for a token, the client sends the original verifier — proving it's the same entity that started the flow.
PKCE was originally designed for mobile apps where client secrets can't be kept confidential, but it's now recommended for all OAuth 2.0 clients — including server-side applications. RFC 9700 (OAuth 2.0 Security Best Current Practice) makes PKCE mandatory for authorization code flows. Every major identity provider (Auth0, Okta, Azure AD, Google, GitHub, Keycloak) supports it.
- Generate a cryptographically random code_verifier: 43–128 URL-safe characters from [A-Za-z0-9-._~]
- Compute the code_challenge: SHA-256 hash of the UTF-8 encoded verifier
- Base64url-encode the SHA-256 hash (no padding) to get the challenge string
- Send code_challenge + code_challenge_method=S256 in the authorization request; send code_verifier in the token request
| Parameter | Value | Notes |
|---|---|---|
code_verifier | 43–128 chars, URL-safe | Keep secret; generated fresh for each request |
code_challenge | BASE64URL(SHA-256(verifier)) | Sent in authorization request; safe to expose |
code_challenge_method | S256 | Always use S256; never 'plain' |
About this tool
About PKCE Generator
PKCE (Proof Key for Code Exchange, pronounced 'pixie') is an OAuth 2.0 security extension defined in RFC 7636. It prevents authorization code interception attacks by requiring the client to prove, at token exchange time, that it is the same entity that initiated the authorization request — without needing a client secret. PKCE is now mandatory for all public OAuth 2.0 clients (SPAs, native apps, mobile apps) per RFC 9700 best practices and is recommended even for confidential clients.
This generator uses the Web Crypto API (crypto.getRandomValues + SHA-256) to produce a cryptographically random code_verifier of your chosen length (43–128 URL-safe characters), then computes the code_challenge as BASE64URL(SHA-256(verifier)) using the S256 method. The verifier alphabet is restricted to [A-Za-z0-9-._~] per RFC 7636 §4.1. Both values are computed entirely in the browser — nothing is sent to any server.
Use the generated pair in your OAuth 2.0 authorization flow: send code_challenge and code_challenge_method=S256 in the authorization request, store code_verifier securely in memory or session storage, then send code_verifier in the token request. The authorization server recomputes the challenge and confirms it matches. Ideal for SPAs using any OAuth 2.0 / OIDC provider (Auth0, Okta, Azure AD, Google, GitHub, Keycloak, etc.).
PKCE eliminates the need for a client secret in public clients, making it safe to implement OAuth 2.0 in environments where secrets cannot be kept confidential (browser apps, mobile apps). All generation is done locally with the Web Crypto API — the verifier is never transmitted except directly to your authorization server's token endpoint.
Key Features
- Cryptographically random code_verifier (43–128 chars)
- S256 challenge: BASE64URL(SHA-256(verifier))
- RFC 7636 compliant URL-safe alphabet
- Four length presets: 43, 64, 96, 128 chars
- One-click copy per field or copy-all
- Auto-generates on page load
- 100% browser-based — verifier never sent to any server
FAQ
PKCE Generator — Frequently Asked Questions
What is PKCE and why do I need it?
PKCE (Proof Key for Code Exchange) is a security extension for OAuth 2.0 that prevents authorization code interception attacks. Without PKCE, a malicious app on the same device could intercept the authorization code before your app exchanges it for a token. With PKCE, intercepting the code is useless because the attacker doesn't have the code_verifier that was used to generate the code_challenge. PKCE is now mandatory for all public OAuth 2.0 clients (RFC 9700).
What's the difference between code_verifier and code_challenge?
The code_verifier is a secret random string your app generates before the authorization request. The code_challenge is a derived value computed as BASE64URL(SHA-256(code_verifier)). You send the challenge (not the verifier) to the authorization server upfront, then send the verifier at token exchange time. The server recomputes the challenge from the verifier and confirms they match — proving you initiated the request.
What length should I use for code_verifier?
RFC 7636 allows 43–128 characters (between 32 and 96 bytes of random entropy, since 3 bytes encode to 4 base64url chars). The recommended length is 64 characters, which provides 48 bytes of entropy — far more than enough. Longer verifiers aren't meaningfully more secure given the SHA-256 challenge, but they don't hurt either. Always use at least 43 characters.
Why S256 and not plain?
S256 (SHA-256) is the only method you should use. The 'plain' method sends the code_verifier as the challenge — defeating the entire purpose of PKCE because an eavesdropper who intercepts the authorization request already has the verifier. S256 ensures the verifier is never transmitted before the token exchange. Some servers still support 'plain' for backward compatibility, but you should always request S256.
Where should I store the code_verifier?
Store the code_verifier in memory (a variable in your app) for the duration of the authorization flow — from when you generate it until you receive the token. For SPAs with page reloads between the authorization request and the callback, sessionStorage is a reasonable choice (it's tab-scoped and cleared on close). Never store it in localStorage long-term or in a cookie accessible to other tabs.
Does PKCE work with every OAuth 2.0 provider?
Most major providers support PKCE: Auth0, Okta, Azure AD/Entra ID, Google, GitHub, Keycloak, Cognito, and virtually every OIDC-compliant server. A few older or enterprise providers may not — check the provider's documentation for a code_challenge_methods_supported field in their discovery document. If a provider doesn't support PKCE, raise it as a security concern with them.
Tips
- Generate a fresh PKCE pair for each authorization request — never reuse a verifier
- The code_verifier must be kept secret until the token request; the code_challenge is public
- Store the verifier in sessionStorage if you need to persist across a page reload during the OAuth redirect
- Use this tool to test your PKCE implementation by manually verifying the challenge against a known verifier