The anatomy of a URL, part by part
A plain guide to every piece of a URL, from scheme and host to path, query and fragment, and how a parser separates them cleanly.
Scheme, host and port
A URL starts with a scheme such as https, which tells the browser which protocol to speak. After the :// comes the authority, made of an optional userinfo, the host and an optional port. The host is usually a domain like example.com, and the hostname is exactly that domain with no port attached. When a port such as :8080 is present the host value carries it while the hostname stays bare, which is why this tool shows both rows separately. If you omit the port, the scheme decides the default, 443 for https and 80 for http, and the Port row is left empty.
Path and the query string
The path is everything after the host up to a question mark, for example /a/b, and it points at a resource on the server. A question mark begins the query string, a set of key and value pairs joined by ampersands like x=1&y=2. Keys can repeat, so tag=a&tag=b is perfectly valid and carries two values for one name. This parser reads the query with the standard search parameter engine, so every pair lands on its own row, in order, with percent escapes and plus signs already decoded into readable text.
The fragment and userinfo
A hash such as #top starts the fragment, which points at a spot inside the page and is never sent to the server. It is handy for deep links and single-page app routing. Some URLs also embed userinfo before the host, in the form user:pass@host, a legacy way to pass credentials. Storing secrets in a link is risky because it can leak through history and logs, so surfacing the username and password in their own rows makes it easy to notice and strip them before sharing.
Why a real URL parser beats a regex
Hand-rolled regular expressions for URLs almost always miss edge cases, such as encoded characters, internationalized domains, empty ports or unusual schemes. This tool leans on the WHATWG URL standard that browsers implement, so its results match what the browser itself would do when it loads the link. That means punycode conversion for non-ASCII hosts, consistent decoding rules and correct handling of relative versus absolute inputs, without you writing or debugging a single pattern.