UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

URL Parser

Parse URLs into protocol, host, path, query parameters, and hash parts.

About URL Parser

URL Parser dissects any URL into its constituent RFC 3986 components — scheme, authority (userinfo, host, port), path, query string (as individual key-value pairs), and fragment — and presents them in a clean, copyable breakdown. It handles edge cases that trip up manual parsing: IPv6 literal hosts, percent-encoded characters in paths, duplicate query parameter keys, matrix parameters, and relative URLs. Whether you are debugging a malformed OAuth redirect_uri, dissecting a signed S3 URL, tracing a multi-hop redirect chain, or validating UTM campaign parameters, this tool gives you an immediate, accurate structural view without writing a single line of regex. Normalized URL output is also provided alongside the raw component breakdown. All parsing runs using the browser's built-in URL API — nothing is transmitted externally.

Why use URL Parser

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 line, making it trivial to find and verify specific values like access_token or utm_campaign.

OAuth and redirect_uri debugging

OAuth flows fail on exact URL matches. Seeing the redirect_uri decoded and broken into components lets you spot trailing slashes, encoding differences, or extra parameters that cause mismatches.

Signed URL verification

AWS S3, GCS, and Azure pre-signed URLs embed expiry timestamps, signatures, and scope inside 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 correctly formed and present before a campaign launches — malformed UTMs silently break analytics attribution.

Normalized output for consistency

The normalized URL output canonicalizes percent-encoding, lowercases the host, and removes default ports — useful for comparison, deduplication, and database key generation.

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 URL Parser

  1. Paste any URL into the input field. HTTP, HTTPS, FTP, data:, blob:, and custom scheme URLs are all supported.
  2. Click Parse (or press Enter) to see the instant breakdown into scheme, host, port, pathname, search, hash, and origin.
  3. Expand the Query Parameters section to see each key-value pair listed individually — useful for URLs with many parameters.
  4. Check the Normalized URL output for the canonicalized form with consistent encoding and trailing-slash normalization.
  5. For signed or encoded URLs, inspect the Decoded Path and Decoded Query sections for percent-decoded values.
  6. Click Copy JSON to get the full parsed result as a structured object for use in scripts, issue reports, or API debugging.

When to use URL Parser

  • 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

OAuth redirect URI

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

Output: Scheme: https | Host: auth.example.com | Path: /callback | Params: code=abc123, state=xyz, redirect_uri=https://app.example.com/oauth (decoded)

AWS S3 pre-signed URL

Input: https://bucket.s3.amazonaws.com/file.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20240501T120000Z&X-Amz-Expires=3600&X-Amz-Signature=abc...

Output: Scheme: https | Host: bucket.s3.amazonaws.com | Path: /file.pdf | X-Amz-Expires: 3600 (1 hour) | X-Amz-Date: 2024-05-01T12:00:00Z

URL with fragment and UTM params

Input: https://blog.example.com/post/intro?utm_source=newsletter&utm_medium=email&utm_campaign=q2-2024#section-2

Output: Scheme: https | Host: blog.example.com | Path: /post/intro | utm_source=newsletter, utm_medium=email, utm_campaign=q2-2024 | Fragment: #section-2

Tips

  • When debugging OAuth redirect mismatches, compare both the registered and requested redirect_uri side by side in the parser — 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 parsed query parameters to verify when the URL was signed and when it expires without decoding the HMAC signature.
  • Check that your URL encoding is idempotent — if running the URL through the parser twice changes the encoding, your application may be double-encoding or inconsistently percent-encoding characters.
  • Bookmark the parser and use it during code reviews when a PR changes URL construction logic — paste both the old and new URL outputs and compare the parameter lists to catch unintended additions or removals.
  • For analytics UTM URLs, verify that utm_source and utm_medium are always present and non-empty — Google Analytics silently drops sessions with malformed or absent campaign parameters.

Frequently Asked Questions

What is the difference between href, origin, and host in a parsed URL?
href is the full URL string. origin is scheme + host + port (e.g. https://example.com:8080) — the security boundary for same-origin policy. host includes the port if non-default (example.com:8080), while hostname is host without the port (example.com).
How does the parser handle percent-encoded characters?
The tool shows both raw (encoded) and decoded values for path segments and query parameter values. For example, %20 is decoded to a space and %2F within a path segment is decoded to /. The raw form is always preserved alongside the decoded version.
What happens with duplicate query parameter keys?
Duplicate keys are fully supported. If a URL has ?color=red&color=blue, both values are shown individually and preserved in the JSON output as an array under the same key. The browser's URLSearchParams.getAll() method handles this correctly.
Can it parse URLs with IPv6 literal addresses?
Yes. IPv6 literals in bracket notation (e.g. http://[::1]:8080/path) are parsed correctly. The host component returns the bracket-enclosed address, and the hostname returns the address without brackets.
What is the difference between path and pathname?
They refer to the same component — the slash-separated hierarchy after the authority and before the query string. pathname is the term used in the browser URL API (and in this tool); 'path' is the informal name. Neither includes the query string or fragment.
How are relative URLs handled?
Relative URLs (e.g. /about?ref=nav or ../image.png) require a base URL to resolve. The tool prompts for an optional base URL when a relative reference is detected, then resolves and parses the absolute form. If no base is provided, https://example.com is assumed for structural parsing only.
Can I parse data: or blob: URLs?
data: URLs are partially parsed — the tool extracts the MIME type, charset, base64 flag, and encoded data segment. blob: URLs are structurally parsed to show the origin and UUID path. For full data URL decoding, use the Data URL Builder tool.
Is the parser reliable for security analysis of URLs?
The tool uses the browser's native URL API (WHATWG URL standard), which is the same parser used by Chrome and Firefox. It is reliable for structural analysis. For security scanning (detecting open redirects, SSRF payloads, or IDN homograph attacks), specialized security tools provide additional signal beyond structural parsing.

Explore the category

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.