URL Parser

About this tool

URL Parser breaks a URL into its parts using the browser's built-in URL API: protocol, host, port, origin, pathname, query string, hash, and a table of every query parameter with its decoded value. It also shows the normalized URL the browser produces — lowercased scheme and host, default ports removed, dot segments resolved and characters percent-encoded where required — and lets you copy the whole result as JSON. Duplicate query keys each get their own row. If you paste a URL without a scheme, such as example.com/docs, https:// is added for you. Whether you are debugging an OAuth redirect_uri, reading the parameters of a signed S3 URL, or checking UTM campaign tags, this gives you an immediate structural view without writing a regex. Relative paths, data: and mailto: URLs are not supported. All parsing runs in your browser — nothing is transmitted externally.

Why use it

• Query parameter inspection: Long URLs with dozens of parameters are unreadable as a raw string. The parser lists each key-value pair on its own row, making it easy to find and verify values like access_token or utm_campaign.

• OAuth and redirect_uri debugging: OAuth flows fail on exact URL matches. Seeing the redirect_uri value decoded in the parameter table lets you spot trailing slashes, encoding differences, or extra parameters that cause mismatches.

• Signed URL inspection: AWS S3, GCS, and Azure pre-signed URLs embed expiry, signature and scope in query parameters. Parse them to read X-Amz-Expires or sv= values without decoding by hand.

• Campaign URL validation: Verify that UTM parameters (utm_source, utm_medium, utm_campaign, utm_content, utm_term) are present and spelled correctly before a campaign launches.

• Normalized output for consistency: The normalized URL lowercases the scheme and host, removes default ports and resolves ./ and ../ segments — useful for comparison and deduplication.

• No server roundtrip: URLs can contain credentials, session tokens, or PII in query strings. Parsing runs entirely in the browser using the native URL API — no data ever leaves your machine.

How to use

1. Paste a URL into the URL box. Absolute http, https, ftp or ws URLs work best; a bare domain such as example.com/docs gets https:// added.
2. Click Parse URL to see the Protocol, Host, Port and Origin cards.
3. Read the Pathname, Query String and Hash boxes below the cards.
4. Check the Normalized URL box for the form the browser's URL API produces.
5. Scan the Query Parameters table, which lists each key and decoded value on its own numbered row.
6. Click Copy JSON to get the full parsed result as a structured object for scripts, issue reports, or API debugging.

When it helps

• Debugging an OAuth 2.0 or OIDC authorization flow where the redirect_uri is being rejected and you need to compare the registered and requested URIs component-by-component.
• Inspecting a pre-signed cloud storage URL (AWS S3, GCS) to read the expiry timestamp, signature scope, or credential embedded in the query string.
• Validating UTM tracking parameters on marketing campaign URLs before they go live to ensure correct attribution in Google Analytics or Mixpanel.
• Tracing a redirect chain where each hop appends query parameters and you need to isolate what the final effective URL looks like after all transformations.
• Writing URL manipulation code and needing a reference to verify your output against the expected component breakdown for a set of test URLs.
• Debugging a webhook delivery failure where the callback URL may have encoding issues causing the receiving server to reject or misroute the request.

Examples

https://auth.example.com/callback?code=abc123&state=xyz&redirect_uri=https%3A%2F%2Fapp.example.com%2Foauth

Protocol: https | Host: auth.example.com | Port: (default) | Pathname: /callback | Hash: (none)
Query Parameters: code = abc123 · state = xyz · redirect_uri = https://app.example.com/oauth

example.com/docs?color=red&color=blue#top

Protocol: https | Host: example.com | Pathname: /docs | Hash: #top
Normalized URL: https://example.com/docs?color=red&color=blue#top
Query Parameters: color = red · color = blue

HTTPS://Example.COM:443/a%20b/../c?q=caf%C3%A9

Port: (default) | Origin: https://example.com | Pathname: /c
Normalized URL: https://example.com/c?q=caf%C3%A9
Query Parameters: q = café

Tips

• When debugging OAuth redirect mismatches, parse both the registered and requested redirect_uri and compare them — a single trailing slash difference or missing port is enough to cause a mismatch in strict implementations.
• For pre-signed AWS S3 URLs, look for X-Amz-Date and X-Amz-Expires in the Query Parameters table to see when the URL was signed and how many seconds it stays valid.
• Compare your URL with the Normalized URL box — if they differ, your application may be double-encoding or inconsistently percent-encoding characters.
• Use the parser during code reviews when a PR changes URL construction logic — paste both the old and new URLs and compare the parameter tables to catch unintended additions or removals.
• For analytics UTM URLs, verify that utm_source and utm_medium are always present and non-empty — malformed or missing campaign parameters break attribution.

Frequently Asked Questions

Glossary

RFC 3986

The IETF standard defining the generic URI syntax. It specifies the component structure (scheme, authority, path, query, fragment) and the percent-encoding rules for characters that are not unreserved. URIs and URLs are defined relative to this spec.

Origin

The combination of scheme, host, and port that defines a security boundary in web browsers. Resources from the same origin can share data freely; cross-origin access is restricted by CORS policy.

Query string

The portion of a URL after the ? character, containing key-value pairs separated by & ampersands (e.g. ?page=2&sort=desc). Values may be percent-encoded. The order of parameters is not semantically significant per RFC 3986.

Fragment identifier

The portion of a URL after the # character. It is processed entirely client-side — the fragment is never sent to the server in HTTP requests. Used for in-page anchors and by single-page app routers.

Percent-encoding

The mechanism for encoding reserved or non-ASCII characters in a URL by replacing them with a % sign followed by two hexadecimal digits representing the byte value (e.g. space → %20, / → %2F when inside a path segment).

WHATWG URL standard

The living standard maintained by the WHATWG that defines how browsers parse URLs. It supersedes RFC 3986 in browser contexts and is implemented as the window.URL API. It handles some edge cases (like missing schemes) differently from the RFC.