OAuth PKCE Request Builder

Generate S256 PKCE values, then build HTTPS authorization URLs and token-request text locally.

RFC 7636 · S256

OAuth PKCE request builder

Generate a verifier, challenge, state, and nonce, then assemble an HTTPS web-client authorization URL and token-request text locally.

Browser only

Do not paste a client secret, access token, password, or production user data. This tool has no field for secrets and sends no OAuth authorization or token request. Generated and entered OAuth values remain in this page unless you copy them, and fixed usage events described on Privacy never contain those values. Nothing is saved to local storage. Treat the verifier, state, nonce, and authorization code as short-lived transaction data.

Enter the exact registered OAuth settings

Values are never guessed. This bounded workflow requires HTTPS for both endpoints and the redirect URI; native-app loopback and custom URI-scheme redirects are outside its scope.

Authorization endpoint

Token endpoint

Client ID

Exact redirect URI

Scopes (space-separated)

Include nonce in the authorization URLEnable this only when using OpenID Connect and the provider expects a nonce.

Generate one transaction’s secure values

A 32-byte verifier is transformed with SHA-256 and unpadded base64url. Generate fresh values for every authorization attempt.

Code verifier — keep private

S256 code challenge — send in authorization request

State — verify on callback

Nonce — verify in an OpenID Connect ID token

Build the authorization URL

Copy the result into your application or browser only after checking it against the provider's documentation.

Authorization URL

Build the token request template

After the callback, paste only its short-lived authorization code. This tool formats the OAuth POST request but never sends that request.

Authorization code from the callback

HTTP request template

This tool processes its input contents in your browser instead of sending them to a processing service. Page, asset and fixed usage-measurement requests are described on the Privacy page.

Generates one S256 PKCE transaction and builds validated HTTPS web-client authorization and token-request text without opening or sending either request.

How to use it

1Enter the exact HTTPS endpoints, public client ID, registered HTTPS redirect and scopes.
2Generate a fresh verifier, challenge, state and optional OpenID Connect nonce.
3Build and copy the authorization URL, then format the token request after receiving a short-lived code.

Example

Input: https://identity.example.test/authorize · client public-client-123 · scope openid profile
Output: response_type=code · S256 challenge · state · optional nonce · exact redirect URI

The complete deterministic URL and its non-reusable fixture values appear in the worked example.

What happens to your data

Generated and entered OAuth values stay in component memory: no OAuth authorization or token request is sent, there is no automatic navigation, and the values are not put in browser storage. Fixed usage events described on Privacy contain no OAuth values. Copy explicitly writes sensitive transaction text to the system clipboard; never enter a client secret.

Last updated November 2026

Prepare the moving parts of an OAuth 2.0 authorization-code request with PKCE without sending an OAuth authorization or token request. The page generates a code verifier, its S256 challenge, a state value and an optional OpenID Connect nonce. Enter the exact HTTPS authorization endpoint, token endpoint, public client ID, registered HTTPS redirect URI and scopes to build copyable authorization-URL and token-request text.

This is a bounded HTTPS web-client builder, not an OAuth client, callback listener or provider login. It does not open the authorization URL, exchange a code, receive tokens, discover provider metadata or accept a client secret. Native-app loopback and custom URI-scheme redirects require the RFC 8252 rules and are deliberately outside this page's validation scope.

How it works

Each generation starts with 32 cryptographically random bytes. Unpadded base64url turns those bytes into a 43-character verifier permitted by RFC 7636. SHA-256 of the verifier's ASCII bytes becomes the 43-character S256 challenge. State and nonce use separate 32-byte random draws; nonce is added to the URL only when the OpenID Connect option is selected. Regenerating immediately removes the previous transaction, authorization URL and token template before hashing begins, so a failure or stale completion cannot leave old credentials under a new attempt.

The authorization builder sets response_type=code, client_id, redirect_uri, scope, state, code_challenge and code_challenge_method=S256, plus the optional nonce. Existing endpoint query parameters are retained unless they collide with a managed OAuth parameter. Complete HTTPS URLs, exact surrounding whitespace, embedded credentials, fragments, control characters and length limits are checked before output. The token template is an application/x-www-form-urlencoded POST body containing grant_type, code, the same redirect URI, client ID and verifier. It is text only and is never executed.

No field requests a client secret, password, access token or refresh token. No generated value is put in page storage, a query string belonging to Toolvore or an automatic navigation. Explicit Copy uses the operating-system clipboard, which can be observed by extensions or clipboard managers outside this page. Your application must keep the verifier and state bound to one short-lived transaction, compare returned state, validate nonce when using OpenID Connect, validate tokens, enforce an exact redirect allowlist and follow the provider's documentation. PKCE reduces authorization-code interception risk; it does not cure cross-site scripting, an open redirect, a malicious authorization server, token leakage or incorrect callback validation.

Worked example: Build a checked authorization URL from a deterministic fixture

Input: Authorization endpoint: https://identity.example.test/authorize?tenant=acme Client ID: public-client-123 Redirect: https://app.example.test/oauth/callback Scopes: openid profile Include nonce: yes Challenge: VtX6czP210fbQsI5QH5dpMMvTHnzXQkrE0_TWkAtnFw State: AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI Nonce: AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM
Result: https://identity.example.test/authorize?tenant=acme&response_type=code&client_id=public-client-123&redirect_uri=https%3A%2F%2Fapp.example.test%2Foauth%2Fcallback&scope=openid+profile&state=AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI&nonce=AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM&code_challenge=VtX6czP210fbQsI5QH5dpMMvTHnzXQkrE0_TWkAtnFw&code_challenge_method=S256

The helper test produces this exact URL from deterministic bytes so the output is reproducible. Those fixture values are intentionally predictable and must never be reused for a real transaction.

Common use cases

Checking the exact encoding of an HTTPS authorization-code request
Preparing a reproducible PKCE request while debugging a public web client
Confirming that the token body repeats the registered redirect URI and verifier
Teaching the relationship between verifier, S256 challenge, state and nonce
Comparing generated parameters with a provider's documented requirements

Frequently asked questions

Does this page contact my identity provider?＋

No. It builds text and never fetches, opens or submits either identity-provider endpoint. Toolvore's separate fixed usage events are described on the Privacy page and contain no endpoint, client ID, verifier, state, nonce, authorization code or generated request text. Copying the authorization URL or token template is an explicit user action; what another application does with it is outside this page.

Should I paste a client secret here?＋

No. A browser-based public client cannot keep a static secret confidential, and this page has no client-secret field. Follow the provider's confidential-client flow in an appropriate trusted backend when a secret is required.

Why are HTTP localhost and custom app schemes rejected?＋

This page deliberately validates only HTTPS web redirects. Installed apps can use loopback and claimed or private-use schemes under RFC 8252, but their platform-specific redirect and app-link checks are outside this bounded workflow.

Does PKCE replace state or OpenID Connect nonce?＋

No. PKCE binds the code exchange to the verifier. State binds the callback to the initiating transaction and helps defend against request forgery. Nonce has a separate OpenID Connect replay-binding role when an ID token is involved.

Can I use the generated values for a production login?＋

Treat this page as a request-building and debugging aid. A real client must retain values securely across the redirect, validate the callback and tokens, apply provider rules and avoid exposing the verifier or authorization code in logs, history or support messages.