URL Parser & Builder

Decompose any URL into its components and rebuild it from the parts

Components Edit any field to rebuild the URL
Scheme
Host
Port
Path
Query Parameters
No query parameters
Fragment (#)
Decoded Parameter Values

URLs in Authentication

Why URL structure matters in OAuth2 and OIDC

Redirect URIs

OAuth2 requires exact redirect URI matching. A mismatched scheme, host, path, or trailing slash causes authorization failures. Parse both the registered and actual URI to spot differences instantly.

Authorization Requests

The OAuth2 authorization endpoint URL carries all request parameters — client_id, scope, response_type, state, nonce, PKCE challenge — as query parameters. Parse them to audit what's being requested.

Debugging Callbacks

After an OAuth2 flow, the callback URL contains the authorization code, state, and sometimes error details as query parameters. Parse the full callback URL to extract and verify each value.

URLs in OAuth2 flows

The components that trip people up

Scheme and host are case-insensitive; the path is not. The default port is implicit, so https://example.com and https://example.com:443 address the same resource but are different strings — which matters wherever exact matching is required.

The fragment after # is never sent to the server. It exists purely client-side, which is why the deprecated implicit flow returned tokens there, and why fragments are forbidden in redirect URIs.

Encoding

Reserved characters must be percent-encoded inside a query parameter value. A redirect URI carried inside an authorization request needs its own encoding, so https://app.example.com/callback becomes https%3A%2F%2Fapp.example.com%2Fcallback.

Double-encoding — %253A instead of %3A — happens when two layers each encode the value. The server decodes once, gets a mangled string, and the comparison fails in a way that's invisible unless you look closely.

Why exact matching matters here

The OAuth2 spec requires exact string comparison of redirect URIs. There is no normalization, so a trailing slash, a port, or a case difference in the path all break the match.

This is intentional. The redirect URI decides where authorization codes are delivered, and any fuzziness in matching becomes somewhere an attacker can redirect a code to a destination they control.

Frequently asked questions

Check for a trailing slash, an explicit versus implicit port, http versus https, localhost versus 127.0.0.1, and case differences in the path. All are common, and all are invisible at a glance.

No. Everything after # stays in the browser. Server logs and backend handlers never see it, which is why it can't be used for anything the server needs.

Whenever a URL appears as the value of a query parameter — as a redirect_uri does inside an authorization request. Reserved characters like : and / must be encoded so they aren't read as structure of the outer URL.

It's when a value is percent-encoded twice, so % itself gets encoded: %3A becomes %253A. Look for %25 sequences in a value that should be a plain URL. Decoding twice recovers the original.

Yes. An origin is scheme, host, and port. https://example.com and https://example.com:8443 are different origins for CORS and for WebAuthn relying party checks, even though the host matches.

Building authorization URLs by hand?

Our SDKs construct them for you — correct encoding, PKCE, state, nonce, and scopes, without assembling query strings yourself.

Free, unlimited users. No credit card required.