ZeroTool Workbench

PKCE Generator

Generate cryptographically secure PKCE code_verifier and code_challenge pairs for OAuth 2.0 / 2.1 flows. S256 and plain methods, 100% browser-based — no network calls.

100% Client-Side Your data never leaves your browser Free · No Sign-Up
0 43–128 chars · [A-Z a-z 0-9 -._~]

Challenge Method

Code Challenge
—
Authorization URL preview paste & tweak for your provider
—
Token exchange (cURL) send verifier on /token 
—

All randomness, hashing and URL preview happens in your browser. Nothing is uploaded.

Related Tools

JWT Decoder Decode and inspect JWT header, payload, and signature. Highlights expiry status and timestamp claims. JWT Generator / Signer Generate and sign JWT tokens (HS256, HS384, HS512) entirely in your browser. Paste or edit header and payload JSON, set your secret, and copy the signed token. Hash Generator Generate MD5, SHA-1, SHA-256, SHA-384, and SHA-512 hashes from any text. Basic Auth Header Generator Generate and decode HTTP Basic Authentication headers in your browser. Copy Authorization headers, tokens, cURL snippets, and Fetch examples with no upload. Password Generator Generate cryptographically secure passwords. Customize length and character sets with entropy meter. RSA Key Pair Generator Generate RSA key pairs (2048/4096-bit) in PEM or JWK format. 100% client-side — keys never leave your browser.

How to Use

  1. The tool auto-generates a 64-character code_verifier the moment the page loads.
  2. Click Regenerate to get a fresh random verifier, or paste your own.
  3. Pick the challenge method — keep S256 unless you have a strong reason to fall back to plain.
  4. The code_challenge updates instantly. Copy it into your /authorize request.
  5. Expand Authorization URL preview to plug in your endpoint, client_id, and redirect_uri.
  6. Expand Token exchange (cURL) to grab a ready-to-run command for the /token call.

Common Use Cases

  • Local OAuth debugging: Generate a verifier/challenge pair, copy the authorize URL into your browser, capture the code, and replay the token exchange with the curl preview.
  • Native + mobile apps: Manually craft test flows for desktop / iOS / Android clients without spinning up a sample backend.
  • Onboarding new providers: Verify that an OAuth provider accepts S256 and that your client_id is configured correctly before writing any code.
  • Security review: Confirm the verifier character set and length against RFC 7636 with a live tool instead of reading the spec mid-review.

How It Works

  1. 32 random bytes from crypto.getRandomValues are base64url-encoded and truncated to your target length.
  2. For S256, the verifier is UTF-8 encoded and hashed with crypto.subtle.digest(‘SHA-256’, …).
  3. The 32-byte hash is base64url-encoded (replace + with -, / with _, strip = padding) to produce the 43-character challenge.
  4. For plain, the challenge equals the verifier — kept for compatibility, not recommended.

FAQ

What is PKCE and why do I need it?

PKCE stands for Proof Key for Code Exchange (RFC 7636). It prevents authorization code interception on public clients — mobile apps, single-page apps, CLI tools, and desktop apps where you cannot safely store a client secret. OAuth 2.1 makes PKCE mandatory for every client, not just public ones.

Should I use S256 or plain?

Always S256 in production. The plain method exists only for legacy clients that genuinely cannot compute SHA-256, which is no longer a realistic constraint. RFC 7636 explicitly recommends S256 and most modern OAuth providers reject plain by default.

Does this tool send my verifier anywhere?

No. Random bytes come from crypto.getRandomValues, hashing happens via crypto.subtle.digest, and the URL preview is concatenated as plain strings. Nothing leaves your browser, and nothing is persisted to localStorage either — the verifier is regenerated fresh each time you reload.

How long should the verifier be?

RFC 7636 allows 43 to 128 characters using the character set [A-Z a-z 0-9 - . _ ~]. We default to 64 characters: high enough entropy to resist brute force, short enough to fit comfortably in URLs. Choose 128 if you want to maximise entropy and your provider accepts it.

How do I use this with my OAuth provider?

Store code_verifier securely on your client (localStorage for browsers, secure storage for native apps). Send code_challenge and code_challenge_method=S256 as query parameters on the /authorize redirect. When you exchange the authorization code at /token, send the original code_verifier so the server can re-hash and compare.