¿Odias los anuncios? Ir Sin publicidad Hoy 

PKCE Code Verifier & Challenge Generator

DesarrolladorSeguridad

ANUNCIO · ¿ELIMINAR?

APORTE

PROD.

Lado cliente

ANUNCIO · ¿ELIMINAR?

Guía

PKCE Code Verifier & Challenge Generator

Generate RFC 7636-compliant PKCE values right in your browser. Pick a verifier length (43–128 characters), and the tool produces a cryptographically random code_verifier together with the matching SHA-256 code_challenge in base64url form, ready to drop into any OAuth 2.0 or OAuth 2.1 authorization request. Useful for SPAs, mobile apps, native CLIs, and anyone debugging an authorization-code-with-PKCE flow against providers like Auth0, Okta, Microsoft Entra, Google, GitHub, and Keycloak.

Cómo Usar

Arrastra el Verifier Length slider — anything from 43 to 128 works; longer values give more entropy.
Elige el Challenge Method. Leave it on S256 unless your provider explicitly requires plain.
Elige un Verifier Charset. Both options are RFC-compliant; the base64url alphabet matches what most OAuth client libraries emit.
Haz clic en Generar. The verifier, challenge, and method appear instantly, along with a step-by-step breakdown of the SHA-256 → base64url transformation.
Copy the code_challenge + code_challenge_method into your /authorize redirect, store the code_verifier en sessionStorage, and replay it on /token to finish the exchange.

Características

Cryptographically secure randomness – utiliza crypto.getRandomValues() with rejection sampling so there is no modulo bias on the 66-character unreserved alphabet.
Native SHA-256 – the challenge is computed via the browser’s SubtleCrypto.digest('SHA-256'), so values match what your authorization server will produce.
S256 and plain methods – both code_challenge_method values from RFC 7636 are supported, with S256 selected by default per OAuth 2.1.
Desglose paso a paso – see the raw verifier, the 32-byte SHA-256 hex digest, and the final base64url challenge so you can audit each transformation.
Two charset options – pick the full RFC 7636 unreserved set (A–Z, a–z, 0–9, -, ., _, ~) or the narrower base64url alphabet that most libraries default to.
Length slider, 43 to 128 – stay within the spec without juggling magic numbers.
Copia con un clic on every output field so you can paste straight into Postman, curl, or your client code.
100% del lado del cliente – nothing is sent to a server. The verifier never leaves your browser tab.

 Preguntas frecuentes

What is PKCE and why does OAuth need it?

Proof Key for Code Exchange (PKCE, RFC 7636) is an OAuth 2.0 extension that protects the authorization code flow against interception. The client picks a secret code_verifier, derives a code_challenge from it, and sends only the challenge on the authorize request. When the client later redeems the authorization code at the token endpoint, it sends the original verifier; the server hashes it and compares it to the stored challenge. Even if an attacker intercepts the authorization code, they cannot exchange it without the verifier, which never leaves the legitimate client. OAuth 2.1 makes PKCE mandatory for all clients, public or confidential.
How long should a code_verifier be and why?

RFC 7636 requires the verifier to be between 43 and 128 characters from the unreserved set. The lower bound exists because 43 base64url characters encode 32 random bytes (256 bits) — the minimum entropy considered safe against brute force. Longer verifiers give more entropy but offer no real security benefit past 256 bits. Most reference implementations pick 43, 64, or 128. Choose the longer end if you want defense in depth, but be aware some legacy servers reject anything past 128 because they enforce the spec strictly.
What is the difference between the S256 and plain challenge methods?

, la cookie se envía a S256 the challenge is the base64url-encoded SHA-256 hash of the verifier; with plain the challenge is the verifier itself. The plain method offers no real protection if the authorization request is intercepted — an attacker who sees the challenge already has the verifier. RFC 7636 only allows plain for clients that genuinely cannot compute SHA-256, and OAuth 2.1 disallows it entirely. Production identity providers like Auth0, Okta, Google, and Microsoft Entra reject plain outright, so always use S256 unless you are debugging a constrained embedded client.
What is base64url and how does it differ from base64?

Base64url is a URL-safe variant of base64 defined in RFC 4648 §5. It replaces + con - y / con _ so the encoded string is safe to drop into a query parameter, JWT segment, or path component without further escaping. Trailing = padding is also stripped because the length is implied by the surrounding context. PKCE, JWT, JWE, JWS, and most modern web crypto specs use base64url for exactly these reasons.