A URL looks like a single string but it is actually a small, precisely specified structure with a fixed set of parts, each serving a distinct purpose: the protocol says which scheme to use to fetch the resource, the host says which server to contact, the path says which resource on that server, and the query string carries additional parameters the server or page can read. Understanding which part is which matters constantly, whether you are debugging a redirect, checking a tracking link, or reviewing a URL a teammate pasted into a bug report.
Parsing happens entirely inside your browser using the built in URL object, so this url parser handles every valid address correctly, including unusual ports, internationalised domain names and deeply nested query strings, without needing a hand maintained pattern that inevitably misses an edge case eventually.
When you need to parse url online rather than read it by eye
Short, simple URLs are easy enough to read directly, but a long URL with dozens of encoded query parameters, a mix of percent encoded characters and an unfamiliar port becomes genuinely hard to scan by eye. This is exactly when it helps to parse url online through a dedicated tool rather than squinting at a single unbroken line of text in an address bar or a log file.
It is also the fastest way to settle a specific, narrow question about a URL, such as confirming which port a request actually targets, or whether a redirect destination uses http or https, without needing to write even a single line of code to answer it.
- Debug a redirect or webhook URL by confirming its host, port and path match what you expect.
- Review a tracking or campaign link before clicking it, to see exactly which parameters it carries.
- Extract one specific query parameter's value from a long, densely encoded URL.
- Check whether a URL uses http or https, and which port it targets, before trusting it.
The parts of a URL, explained
The protocol, also called the scheme, is everything before the colon and two slashes, such as https or ftp, and it tells the browser or client which set of rules to use to fetch the resource. The host is the domain name or IP address that identifies which server to contact, and the port, when present, specifies which numbered channel on that server to connect to, defaulting to 443 for https and 80 for http when no port is written explicitly.
The pathname is everything after the host up to the question mark, identifying a specific resource on that server, similar in spirit to a file path on a computer. The search, or query string, starts at the question mark and carries key and value pairs separated by ampersands, which this url parser reads out individually as a proper table rather than one long encoded line. The hash, starting with the pound sign, is a fragment identifier that never gets sent to the server at all, used instead by the page itself, typically to jump to a specific section or to pass state to client side code.
Reading query parameters without decoding them by hand
Query string values are frequently percent encoded, meaning spaces, ampersands and other special characters are replaced with a percent sign followed by two hex digits so they cannot be confused with the query string's own separator characters. Reading that encoding by eye is tedious and genuinely error prone for anything beyond a couple of simple values.
This tool decodes every parameter automatically and displays each key alongside its decoded value in a table, so a parameter like search=web%20design tools shows immediately as the readable phrase web design tools rather than the raw percent encoded original. That decoded view is usually what you actually want when auditing a link, since the encoding is a transport detail rather than the meaningful content of the parameter.
Why this url parser never touches a regular expression
Every field in the breakdown comes directly from the browser's native URL object, which fully implements the WHATWG URL Standard, the specification that defines exactly how a browser parses, normalises and serialises a web address. Query parameters specifically are read using URLSearchParams, the companion interface built for iterating and decoding a query string's key and value pairs correctly.
Because both of those are the same primitives every browser uses internally to navigate the web, this url parser produces results that always match how your own browser would actually interpret the same address, rather than approximating it with a separate, potentially inconsistent parsing library. Nothing you paste is ever transmitted anywhere, since parsing runs entirely on your device.
| Component | Example | Meaning |
|---|---|---|
| Protocol | https: | Which scheme to use to fetch the resource |
| Host | example.com | The server to contact |
| Port | 8080 | The numbered channel on the server, defaults by protocol |
| Pathname | /products/shoes | The specific resource on the server |
| Search | ?color=red&size=9 | Query parameters sent to the server |
| Hash | #reviews | A fragment used by the page, never sent to the server |
How to use this url parser
- 1
Paste a full URL
Enter a complete web address, including its protocol, into the input box.
- 2
Run the parser
Press parse to break the address down using the browser's native URL constructor.
- 3
Review the component breakdown
Check the protocol, host, port, pathname and hash shown alongside the address.
- 4
Inspect the query parameters table
Read every query string parameter with its value already decoded for you.
Related tools worth bookmarking
Sources and further reading
- MDN: URLThe browser API this tool uses to parse every component of a web address.developer.mozilla.org
- WHATWG URL StandardThe living specification that defines exactly how browsers parse, normalise and serialise a URL.url.spec.whatwg.org
- RFC 3986: Uniform Resource Identifier (URI): Generic SyntaxThe foundational specification defining the generic components a URL is built from.rfc-editor.org
Frequently asked questions
Common questions about the url parser.
The browser's URL constructor requires a complete, correctly structured address, including a protocol such as https, to parse it successfully. A bare domain name or path fragment without a protocol will be rejected, so add https to the front of the address and try again.
The pathname is everything after the host up to the question mark, identifying a specific resource on the server, similar to a file path. The query string starts at the question mark and carries additional key and value parameters, which this url parser reads out individually in a decoded table rather than as one long encoded line.
No. The hash, or fragment identifier, starting with the pound sign, is used entirely by the browser and the page itself, typically to jump to a section of a document or to pass state to client side code, and it is never included in the actual network request sent to the server.
Yes. When a query string contains the same parameter name more than once, each occurrence is read out as its own row in the parameter table, in the exact order it appears in the original URL, matching how URLSearchParams itself iterates repeated keys.
No. The URL and URLSearchParams objects this tool uses are the same constructors your browser calls internally when it navigates to a page, and calling them on a string you paste in does not itself trigger a fetch or a navigation. Every field in the breakdown comes back from that constructor synchronously, so a URL containing a session token or an internal hostname is inspected without ever being requested.
Yes, in practice. A url structure checker and this url parser do the same job: confirming that an address is valid and showing exactly what each of its parts contains. If the URL fails to parse here, that is a reliable signal it is malformed or missing a required piece, most commonly the protocol.
The full url components breakdown covers the protocol, hostname, port, pathname, search string and hash fragment, plus every query parameter decoded individually in its own table row. Together those fields account for every distinct piece the WHATWG URL Standard defines for a web address.
When a URL does not specify a port explicitly, it uses its scheme's default port, 443 for https and 80 for http, and the browser's URL object leaves the port field empty in that case rather than filling in the implied default value. The connection still uses the correct default port even though it is not shown explicitly.