OAuth PKCE Generator
Draw a code verifier and work out the matching code challenge for an OAuth 2.0 sign-in, ready to paste into an authorization request. Both are made on your device and never leave your browser.
PKCE is what keeps an OAuth sign-in from being hijacked halfway through. Your app invents a secret — the code verifier — sends only a fingerprint of it with the sign-in request, then produces the original at the end to prove the code came back to the app that asked for it. This makes both halves, ready to paste into a request or a test.
Your code verifier
Strength: Strong, 386 bits
Your code challenge
S256Send this with the authorization request, as code_challenge, together with code_challenge_method=S256. It gives nothing away about the verifier.
Customize
RFC 7636 fixes the range at 43 to 128 characters, and the bottom of it already carries more randomness than the spec asks for. Longer is not stronger in any way that matters; a few servers do trip over values near the ceiling.
Characters used
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~
These 66, and no others. The spec picked them because every one survives a query parameter untouched, so the verifier that arrives at the token endpoint is the one that left.
Recent verifiers
Nothing here yet. Verifiers you generate are kept on this device only, so you can pick one up again while you are still testing a flow.
How the two halves fit together
An OAuth sign-in comes back to your app as a short-lived code in a redirect, and a redirect passes through places you do not control — a browser history, another app that registered the same URL scheme, a log on the way. PKCE closes that gap by making the code useless on its own. Your app draws a verifier, keeps it, and sends only the challenge with the sign-in request; at the end it presents the verifier, and the server checks that it produces the challenge it was given at the start. Whoever intercepted the code never had the verifier, so they have nothing to present.
The verifier is the secret and the challenge is not. With S256 the challenge is a SHA-256 hash written in URL-safe Base64 — always 43 characters, whatever the verifier's length — and hashing only runs one way, so seeing it tells an attacker nothing they can use. With plain the challenge is the verifier itself, which is why OAuth 2.1 removes that option entirely.
Length is the setting people expect to matter here, and it barely does. The 43-character minimum is already 259 bits — RFC 7636 arrives at that floor by recommending 32 random bytes, and 32 bytes written in this alphabet come to 43 characters. Going up to 128 adds bits nobody was ever going to search through. What actually decides the strength of a PKCE exchange is the method above it and the fact that the verifier is drawn from chance rather than derived from a session id, a timestamp or a username.
One pair, one sign-in. A verifier is spent the moment it is exchanged for a token, and reusing one across sign-ins hands anybody who saw it once a way into the next. Draw a fresh pair for every attempt, keep the verifier where the rest of your app cannot read it — session storage for a web app, the platform keystore for a mobile one — and throw it away once the token comes back.
Nothing generated here is registered with anyone. These are values you paste into your own request, and the pair only means something once your app sends the challenge and holds on to the verifier.
Everything happens on your device. Your code verifiers never leave this browser.