Zero Signup ToolsFree browser tools

Developer Tools

PKCE Generator

Generate an OAuth 2.0 PKCE code verifier and code challenge (S256 or plain) with state and nonce. RFC 7636 compliant. Runs in your browser.

PKCE generator

Generate PKCE pair

code_verifier and code_challenge

The verifier is a random string from the RFC 7636 unreserved set. The challenge is derived from it using your chosen method. Keep the verifier private and send only the challenge in the authorization request.

RFC 7636 requires 43 to 128 characters. About 387 bits of entropy at this length.

PKCE values

  • code_verifier

    __0tDqBAdHAXv9bduxmBNZ56.41TyodCMYFO.SEtvIF8kGaR~cKTpyvSqG9Aclit

    Keep this secret. Send it in the token exchange step.

  • code_challenge

    BASE64URL(SHA256(code_verifier)). Send this with the authorization request.

  • code_challenge_method

    S256

    Tells the authorization server how to verify the verifier.

Verifier length

64 chars

Allowed range is 43 to 128.

Verifier entropy

387 bits

log2(66) per character from the unreserved set.

Anti-CSRF and OIDC values

Opaque CSRF token. Store it in session storage before redirect. On callback, compare the returned state to detect cross-site request forgery.

OpenID Connect only. Included in the ID token so the client can detect replay. Plain OAuth 2.0 does not require it.

Authorization request URL

Fill in your authorization endpoint and client details to build a ready-to-open authorize URL. Edits never leave your browser.

authorize URL

https://auth.example.com/authorize?response_type=code&client_id=your-client-id&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&scope=openid+profile+email&code_challenge_method=S256&state=RiSA3HSFOOFpS1ZHH5vnNA

Token exchange snippets

After the authorization server redirects to your redirect_uri with a one-time code, your app exchanges that code plus the original verifier for tokens.

curl

# 1. Open the authorize URL in a browser
#    https://auth.example.com/authorize?response_type=code&client_id=your-client-id&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&scope=openid+profile+email&code_challenge_method=S256&state=RiSA3HSFOOFpS1ZHH5vnNA
#
# 2. After redirect, exchange the code for tokens:
curl -X POST "https://auth.example.com/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "client_id=your-client-id" \
  -d "code=AUTH_CODE_FROM_REDIRECT" \
  -d "redirect_uri=https://app.example.com/callback" \
  -d "code_verifier=__0tDqBAdHAXv9bduxmBNZ56.41TyodCMYFO.SEtvIF8kGaR~cKTpyvSqG9Aclit"

fetch (JavaScript)

// Run this in the callback handler, after validating state.
const body = new URLSearchParams({
  grant_type: "authorization_code",
  client_id: "your-client-id",
  code: AUTH_CODE_FROM_REDIRECT,
  redirect_uri: "https://app.example.com/callback",
  code_verifier: "__0tDqBAdHAXv9bduxmBNZ56.41TyodCMYFO.SEtvIF8kGaR~cKTpyvSqG9Aclit",
});

const res = await fetch("https://auth.example.com/token", {
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body,
});
const tokens = await res.json();

Python requests

import requests

tokens = requests.post(
    "https://auth.example.com/token",
    data={
        "grant_type": "authorization_code",
        "client_id": "your-client-id",
        "code": AUTH_CODE_FROM_REDIRECT,
        "redirect_uri": "https://app.example.com/callback",
        "code_verifier": "__0tDqBAdHAXv9bduxmBNZ56.41TyodCMYFO.SEtvIF8kGaR~cKTpyvSqG9Aclit",
    },
).json()

Node.js (axios)

import axios from "axios";

const params = new URLSearchParams({
  grant_type: "authorization_code",
  client_id: "your-client-id",
  code: AUTH_CODE_FROM_REDIRECT,
  redirect_uri: "https://app.example.com/callback",
  code_verifier: "__0tDqBAdHAXv9bduxmBNZ56.41TyodCMYFO.SEtvIF8kGaR~cKTpyvSqG9Aclit",
});

const { data: tokens } = await axios.post("https://auth.example.com/token", params);

When to use PKCE

  • Public clients (single page apps, mobile apps, native desktop) must use PKCE because they cannot keep a client_secret safe.
  • Confidential clients (web servers with a secret) should still use PKCE as defense in depth. OAuth 2.1 makes it the default.
  • Always prefer S256. The plain method is kept only for clients that genuinely cannot compute SHA-256.
  • Generate a fresh verifier, challenge, state, and (optionally) nonce for every authorization request. Reuse opens the flow to replay.

How the flow works

  1. 1. Client generates code_verifier and derives code_challenge.
  2. 2. Client redirects the user to the authorize endpoint with the challenge, method, state, scope, and redirect_uri.
  3. 3. User authenticates. Authorization server redirects back to redirect_uri with a one-time code and the original state.
  4. 4. Client verifies state, then POSTs to the token endpoint with the code and the code_verifier.
  5. 5. Authorization server recomputes the challenge from the verifier and compares to the one sent in step 2. If they match, tokens are returned.

How to use

  1. Pick S256 (recommended) or plain as the challenge method. Most OAuth providers require S256.
  2. Adjust the verifier length between 43 and 128 characters. Longer verifiers add entropy; 64 is a good default.
  3. Click Generate new pair to roll a fresh code_verifier, code_challenge, state, and nonce. Use New verifier (keep state and nonce) to rotate just the PKCE pair.
  4. Fill in your authorize endpoint, client_id, redirect_uri, and scope to build a working authorization URL with the challenge embedded.
  5. Copy the verifier into your session storage before redirecting the user. After callback, use the matching token exchange snippet (curl, fetch, Python, or Node) to swap the code plus verifier for tokens.

About this tool

PKCE Generator builds the cryptographic values an OAuth 2.0 or OAuth 2.1 client needs for the Proof Key for Code Exchange extension (RFC 7636). It generates a random code_verifier from the RFC 7636 unreserved character set [A-Z][a-z][0-9]-._~ at any length from 43 to 128 characters, then derives the matching code_challenge two ways: S256 (BASE64URL(SHA256(verifier)), the recommended default and the only method accepted by most modern providers) and plain (challenge equals verifier, kept for legacy clients). It also produces a fresh, opaque state value to defend against CSRF on the redirect callback and an optional nonce value for OpenID Connect ID-token replay protection. A live authorization request builder threads your authorize endpoint, client_id, redirect_uri, scope, and optional audience through a working query string so you can click into Auth0, Okta, Cognito, Microsoft Entra, Google, Keycloak, or any RFC 6749 server immediately. Below the values are ready-to-paste token exchange snippets for curl, browser fetch, Python requests, and Node.js axios, each one pre-populated with your verifier so you can complete the token step end to end. Everything runs in the browser. Randomness comes from crypto.getRandomValues, the SHA-256 hash uses crypto.subtle.digest, and base64url encoding follows RFC 4648 section 5 (no padding). No verifier, challenge, state, or nonce is ever sent over the network. Use this for testing OAuth flows, building example requests, debugging redirect bugs, or grabbing a one-off PKCE pair for a quick API integration.

Free to use. Works in your browser. No signup, no login.

Related tools

You may also like

All tools
All toolsDeveloper Tools