URL Parser

The URL Parser breaks any web address into its individual components — scheme, host, port, path, query parameters, and fragment — so you can inspect or debug it at a glance. It is built for developers debugging redirects, marketers checking tracking parameters, and anyone wondering what each part of a long URL actually does.

Anatomy of a URL

A URL looks like a single string, but it has a strict structure defined by RFC 3986. Consider:

https://shop.example.com:8080/products/list?page=2&utm_source=newsletter#reviews

Read left to right, the parts are:

Part	Value	Meaning
Scheme	https	The protocol the browser speaks
Host	shop.example.com:8080	Server name plus optional port
Port	8080	Explicit; 443 and 80 are implied and hidden
Pathname	/products/list	The resource on that server
Search	?page=2&utm_source=newsletter	Query parameters
Hash	#reviews	In-page anchor, never sent to the server

Knowing which slice is which makes redirects, tracking bugs, and API callbacks far less painful to reason about.

Reading the Result Cards

The top row of cards shows scheme, host, port, pathname, search, and hash exactly as the parser stores them. Below that a second panel splits the host into subdomain, domain, and TLD. For the example above, the host breakdown is:

• Subdomain: shop
• Domain: example
• TLD: com

The final panel is a table of query parameters, one row per key and value, with all percent-encoding decoded for readability. Every card can be copied independently, so you can lift just the pathname into a log or just the port into a config file.

Worked Example: A Campaign URL

Marketing links are where URL structure gets messy. Take:

example.com/lp?utm_source=news&utm_medium=email&utm_campaign=spring%20sale&ref=abc123

Because the scheme is missing, the tool adds https:// automatically. The host becomes example.com with no subdomain, path is /lp, and the parameter table reads:

• utm_source = news
• utm_medium = email
• utm_campaign = spring sale
• ref = abc123

Notice that spring%20sale was decoded to spring sale in the table while the raw search card still shows the encoded string. That split is useful: use the table to read values, and the search card to copy the literal query that the server receives.

How the Tool Splits Domains

Domain splitting is the part of URL parsing that has no perfect built-in answer, because suffixes such as co.uk behave like a single TLD but are really two labels. The parser handles this with a small allowlist of common multi-part suffixes and a simple fallback otherwise:

1. If the hostname is an IPv4 address or localhost, it is treated as the domain with no TLD.
2. Otherwise, the last label is taken as the TLD.
3. If the host has at least three labels and the last two form a known suffix, that two-label suffix becomes the TLD and the label before it becomes the domain.

So www.example.co.uk yields subdomain www, domain example, and TLD co.uk. But www.example.co.za is not on the list, so it yields subdomain www.example, domain co, and TLD za — technically wrong, and a good reminder that public-suffix logic needs a much larger dataset than a fixed list.

Debugging Tips and Why Structure Matters

A URL is an interface contract. The scheme decides the protocol, the host and port choose the server, the path selects the resource, the query carries application state, and the fragment stays on the client. When any of those pieces drifts, the failure usually shows up somewhere far away — an analytics report with missing campaign data, an OAuth callback that lands on the wrong route, or a CDN that caches two URLs it considers distinct. Parsing the address into named fields turns a fuzzy debugging session into a checklist: is the host right, is the port the one you expect, are the query keys spelled the same as in the code, and does the fragment point at an element that still exists?

For tracking audits, paste the live URL and confirm the parameters you expect are present, spelled correctly, and not duplicated — duplicate utm keys are a common cause of skewed analytics. For redirect chains, parse each hop and compare the pathname and host; a stray trailing slash or a port that vanished usually explains an unexpected 301. For API work, copy the decoded query table to check that values match your documentation before you build the signing string, since percent-decoding differences are a frequent source of signature mismatch.

Edge Cases and Common Mistakes

• Default ports disappear. https://example.com:443/ shows an empty port and https://example.com/ after normalization.
• International domains become punycode. Enter https://münchen.de and the hostname card shows the ASCII form xn--mnchen-3ya.de, because that is how the browser stores it for DNS.
• Trailing slashes matter. /products and /products/ are different pathnames even when a server treats them the same.
• Empty queries return no rows. A trailing ? or no query at all produces an empty parameter table rather than a blank row.
• Invalid input fails cleanly. A string the browser cannot parse shows an “Invalid URL” message instead of a misleading partial breakdown.
• Assuming the encoded value is the real value. The parameter table shows decoded text, so a search for a%26b appears as a&b. Use the raw search card when you need the exact bytes the server receives.
• Reading the host card as the domain. The host includes the port and any subdomain; the domain card is just the registrable label.
• Trusting the TLD split for every country. example.co.za and example.com.br are two-level suffixes that the fixed allowlist misses, so the domain card will show co or com by mistake.
• Forgetting that paths are case-sensitive. /Products and /products can be different routes even on the same server.
• Treating a bare word as a valid host. not a url gets https:// prepended and may parse oddly; check the host card before trusting the result.

Related Tools

• URL Encoder
• IP Address Lookup
• JWT Decoder