SECURITY

OAuth URL Builder

Build an OAuth 2.0 / OIDC authorization URL with PKCE, provider presets, state/nonce generation, and a URL decoder.

What this tool does

Builds a correctly formed OAuth 2.0 / OpenID Connect authorization request URL — the link a user is sent to in order to log in and grant access — from a real provider preset or a custom endpoint, with PKCE code generation, random state and nonce values, redirect_uri validation, and the advanced parameters providers actually support. It also works in reverse: paste any existing authorization URL and every parameter is parsed out and explained individually, including a standalone checker for whether a code_verifier/code_challenge pair actually matches.

Why PKCE matters, even for "confidential" clients

PKCE (Proof Key for Code Exchange, RFC 7636) was originally designed for mobile and single-page apps that can't keep a client secret safe. OAuth 2.1 now recommends PKCE for every authorization code flow, confidential clients included, because it closes an authorization-code-interception attack even when a client secret exists. This tool defaults PKCE on and generates a cryptographically random code_verifier (keep this — you'll need it for the token exchange step) and its matching code_challenge (this goes in the URL), using either S256 (SHA-256, the method every current provider supports and the only one that should be used in production) or plain (the challenge is just the verifier, unhashed — kept here only for testing against a non-compliant implementation, and clearly marked discouraged).

state and nonce

state is how the client defends against CSRF — it's an opaque value the client generates, sends in the request, and must verify matches on the callback, so an attacker can't trick a user into completing someone else's login. nonce is OpenID Connect-specific — it ties the issued id_token to this exact request, preventing replay of a token from a different session. Both should be freshly random for every request, never reused — this tool generates both with crypto.getRandomValues().

Choosing a provider and response_type

Provider presets fill in the real authorization endpoint, a sensible default scope, and the token endpoint (shown for reference — the token exchange itself is a server-side step this tool doesn't perform) for Google, GitHub, Microsoft (Azure AD v2), Facebook, GitLab, Discord, Slack, LinkedIn, Spotify, X (Twitter), Apple, Amazon, Twitch, Reddit and Bitbucket — each provider's endpoints and accepted scopes genuinely differ, so getting the base URL right matters before anything else. response_type=code (the authorization code flow) is the right choice for nearly everything built today; the implicit flow (token or id_token without a code) is explicitly deprecated by OAuth 2.1 because it exposes tokens directly in the URL fragment, with no way to use PKCE to protect it — this tool flags it when selected, and separately flags a redirect_uri that isn't a valid absolute URL or uses plain HTTP outside of localhost.

QR export, history, and the session record

The built URL can be shown as a QR code for opening the flow on another device, or downloaded as a complete session record (JSON: every field, the PKCE pair, and the final URL) for scripting or keeping alongside test notes. A session-only history keeps the last 8 URLs built.

Privacy

Everything — PKCE generation, state/nonce, URL building, decoding, and QR rendering — runs locally in your browser. The session history lives only in this tab's memory. Nothing is sent to a server, including the URL you're building or decoding.

FAQ

Frequently asked questions

Is anything I enter here sent to a server?

No. URL building, decoding, PKCE/state/nonce generation, and QR rendering all happen entirely in your browser -- nothing is sent anywhere, including to the provider itself (this tool only constructs the URL, it doesn't open or submit it for you unless you click "Open in new tab" yourself).

Do I need PKCE if my app already has a client secret?

OAuth 2.1 recommends PKCE for every authorization code flow regardless of client type -- it protects against a different attack (interception of the authorization code in transit) than a client secret does, and the two aren't a substitute for each other.

What's the difference between the S256 and plain PKCE methods?

S256 hashes the code_verifier with SHA-256 before it goes in the URL as code_challenge -- this is what every current provider expects and the only method that should be used in production. Plain sends the verifier itself as the challenge, unhashed; it exists in the spec for compatibility testing but provides essentially no protection and is explicitly discouraged.

What do I do with the code_verifier after building the URL?

Keep it (client-side, never send it in the authorization URL itself) -- you'll send it as a parameter in the subsequent token exchange request, which this tool doesn't perform since that's a server-to-server (or confidential client) step, not a URL to visit. The token endpoint shown for your selected provider is where that exchange happens.

Why does it warn about response_type=token?

That's the OAuth implicit flow, which returns the access token directly in the URL fragment with no authorization code step -- it's explicitly deprecated by OAuth 2.1 because tokens end up exposed in browser history and referrer headers, and it can't be protected by PKCE the way the code flow can.

Can I decode a URL someone else built, not just build my own?

Yes -- switch to Decode, paste any OAuth/OIDC authorization URL, and every query parameter is parsed out individually with a plain-English explanation of what it does. The same view also has a standalone checker for whether a code_verifier and code_challenge pair actually match.

Are the provider presets' endpoints accurate?

They're each provider's real, current, publicly documented authorization and token endpoints -- but providers do occasionally change requirements (required scopes, extra parameters), so always cross-check against that provider's own current OAuth documentation before using this in production.

Can I export the built URL as a QR code, or save the full session?

Yes to both -- a QR code of the current authorization URL (for opening the flow on another device), and a "Download session record" button that saves every field (endpoint, client ID, redirect URI, scope, state, nonce, and the full PKCE pair) as a JSON file.