URL Structure Parser
Paste any URL and see it broken into protocol, host, path segments, decoded query parameters, and fragment, laid out in a table.
About the URL Structure Parser
A URL packs a lot into one string, which protocol to use, which server to contact, which page on that server, and any extra parameters or an in-page anchor tacked onto the end. This tool runs a pasted URL through the browser's own URL constructor (auto-adding https:// if the protocol was left off) and lays out each piece in a table, including every query parameter decoded on its own row and the fragment after the #. The subdomain/domain split shown here is a simple heuristic, everything before the last two dot-separated labels counts as the subdomain, which works for most .com/.net/.org style hosts but isn't accurate for two-part public suffixes like .co.uk or .com.au, where a correct split needs a public suffix list lookup rather than just counting dots.
The fragment never reaches the server at all
Everything after the # is handled entirely by the browser and is never sent as part of the HTTP request to the server, a request for /page#section-2 and a request for plain /page look completely identical from the server's perspective. That has a real consequence for anything relying on the fragment to distinguish content, an old-style single-page app that used fragments to represent different views is invisible to a crawler that only sees the base URL, which is exactly why fragment-based routing was largely abandoned in favor of the History API for anything that needs to be independently crawlable and linkable.
Query parameters preserve both order and duplicates
Unlike a plain object, which can only hold one value per key, the parser here keeps every occurrence of a repeated parameter name as its own row, a URL with ?tag=seo&tag=marketing shows two separate tag entries rather than one overwriting the other. Order is preserved too, exactly as it appeared in the original URL, which matters for debugging an API or tracking setup where parameter order occasionally affects how a receiving system processes the request.
A practical use for a URL that "looks right" but doesn't work
A tracking link or API call that mysteriously isn't picking up a parameter is often down to something easy to miss while reading the raw string, a parameter name with the wrong casing, a stray extra ? that starts a second query string instead of appending to the first, or a value that needed URL-encoding and didn't get it. Laying every parameter out on its own decoded row makes a mismatch like a typo'd key name obvious in a way that's much harder to spot buried in one long unbroken URL string.
Why https:// gets added automatically
Pasting in a bare domain like example.com/page without a protocol still parses correctly, this tool prepends https:// before handing the string to the URL constructor, since a URL parser generally requires a protocol to know where the host ends and the path begins. That's a convenience for pasting in a domain copied from somewhere that doesn't include the protocol, it's not a statement that the URL is actually served over https in reality, that assumption is worth double-checking separately for anything where the protocol genuinely matters.
What the Port row is actually for
Most URLs never specify a port explicitly, browsers default to 443 for https and 80 for http without it needing to be written out, which is why this row shows "default" for the overwhelming majority of real-world URLs. It becomes relevant mainly for local development addresses, something like localhost:3000 or 127.0.0.1:8080, where the port is doing real work identifying which of several services running on the same machine a request is meant to reach.
Frequently Asked Questions
Does the fragment (the part after #) get sent to the server?
No. The fragment is handled entirely by the browser and never included in the actual HTTP request. A request for /page#section-2 looks identical to a request for /page from the server's point of view, which is why fragment-based content isn't reliably crawlable the way path-based URLs are.
What happens if a URL has the same query parameter twice?
Both occurrences are preserved and shown as separate rows, rather than one overwriting the other, matching how the URL actually encodes the data. Order is preserved too, exactly as it appears in the original URL.
Why is the subdomain/domain split wrong for a .co.uk address?
The split used here is a simple heuristic based on counting dot-separated labels, which works for most .com-style domains but not for two-part public suffixes like .co.uk or .com.au. An accurate split for those requires checking against a public suffix list, which this tool doesn't do.
How can this help debug a tracking link that isn't working?
Laying every query parameter out on its own decoded row makes a typo in a parameter name, an extra stray question mark, or a value missing URL-encoding much easier to spot than reading through one long, unbroken URL string.
Does adding https:// automatically mean the site actually uses https?
No, it's just a parsing convenience for pasting in a bare domain without a protocol, a URL parser generally needs a protocol present to correctly separate the host from the path. It's not a verification that the destination is actually served over https, that's worth checking separately if it matters.