How URL Parser works
This URL parser takes one complete address and breaks it into the parts a browser sees: Protocol, Host, Port, Path, the number of query parameters and the Fragment. Below that it lists each query parameter as a key and a decoded value, so blue%20suede reads as blue suede, and it lists the path one segment at a time. Parsing uses the same URL rules that browsers follow (the WHATWG URL standard), so the host is lower-cased, a missing port is reported as 443 for https or 80 for http, and repeated keys are kept as separate rows. The address must start with a scheme such as https://.
URL components, shown on one example
Address: https://shop.example.com:8443/products/shoes?colour=blue%20suede&size=42&utm_source=newsletter#reviews
| Component | Value from the tool | Where it sits in the address |
|---|---|---|
| Protocol | https | Before :// |
| Host | shop.example.com | After :// up to the port or the first slash |
| Port | 8443 | After the colon that follows the host |
| Path | /products/shoes | From the first slash up to ? or # |
| Query params | 3 | Between ? and #, separated by & |
| Fragment | reviews | After # |
| Path segments | products, shoes | The path split at each slash |
The three parameters are listed as colour = blue suede, size = 42 and utm_source = newsletter.
Parsed URL examples
A video link
https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=42s
Host www.youtube.com, Port 443 (default), Path /watch, 2 query params: v = dQw4w9WgXcQ and t = 42s
A campaign link with UTM tags
https://example.com/blog/2026/launch-notes/?utm_source=newsletter&utm_medium=email&utm_campaign=spring%20sale#pricing
Path /blog/2026/launch-notes/, Fragment pricing, 3 query params: utm_source = newsletter, utm_medium = email, utm_campaign = spring sale
Path segments are blog, 2026 and launch-notes.
A redirect that carries another URL
https://example.com/login?next=https%3A%2F%2Fexample.com%2Faccount%3Ftab%3Dbilling
1 query param: next = https://example.com/account?tab=billing
Paste the decoded value back in to parse the inner address as well.
A repeated key and a plus sign
https://example.com/search?q=red+shoes&tag=a&tag=b
3 query params: q = red shoes, tag = a, tag = b
A local development address
http://localhost:3000/api/v1/users?id=7
Protocol http, Host localhost, Port 3000, Path /api/v1/users, 1 query param: id = 7. Path segments: api, v1, users
No scheme
example.com/path
Error: That is not a complete URL. Include the scheme, for example https://example.com/path.
How query string values are decoded
The Decoded value column applies the form-encoding rules browsers use for query strings.
| Written in the URL | Decoded value | Note |
|---|---|---|
| blue%20suede | blue suede | %20 is a space |
| red+shoes | red shoes | A plus sign is also a space in a query string |
| 10%2B5 | 10+5 | A real plus sign must be sent as %2B |
| caf%C3%A9 | café | Non-ASCII characters are UTF-8 bytes, each percent-encoded |
| https%3A%2F%2Fexample.com | https://example.com | %3A is a colon and %2F is a slash |
| empty= | (empty value) | A key with nothing after = has an empty value |
| flag | (empty value) | A key with no = is kept, also with an empty value |
Because + becomes a space, a phone number sent as phone=+4420 decodes with a leading space in place of the plus.
What the parser normalises or leaves out
The result follows browser behaviour, which differs from the raw text in a few ways.
- The scheme and host are lower-cased: HTTPS://Example.COM/Path is reported as protocol https, host example.com and path /Path.
- Dot segments are resolved, so /A%20B/../c is shown as the path /c.
- The Path and Path segments stay percent-encoded. Only query parameter keys and values are decoded.
- An internationalised host is shown in its Punycode form, for example xn--mnchen-3ya.de for münchen.de.
- A user name and password written before the host (user:pass@) are accepted but not displayed.
- Only & separates parameters. A semicolon is treated as part of the value, so ?x=1;y=2 is one parameter.
- A query string placed after the # belongs to the fragment and is not split, as in https://example.com/#/dashboard?tab=1.
- For schemes other than http and https, a missing port is shown as a dash.
- A host and port typed without a scheme, such as localhost:3000/api, is not rejected. The text before the colon is read as the scheme, so the result shows protocol localhost, an empty host and the path 3000/api. Add http:// in front to get the real breakdown.
Which parts of a URL reach the server and end up in logs
The host decides where the connection goes and is sent in the Host header. The path and the query string are sent in the request line, so the server sees them and they are normally written to access logs. They are also kept in browser history and, depending on the page's referrer policy, can be passed on in the Referer header.
That is the reason an access token or password should not be put in a query parameter. A request header or the request body is the safer place.
The fragment is the exception. Everything after the # is used by the browser only. A server-side script cannot read it, and an analytics tool that needs it has to run in the page.
Using URL Parser
- 1
Paste a complete address into URL, including the scheme (https://, http://, ftp:// and so on).
- 2
Read the Components panel for Protocol, Host, Port, Path, Query params and Fragment.
- 3
Check the Query parameters table, where each Key is paired with its Decoded value.
- 4
Use the Path segments list to see the path split at each slash.
- 5
If you get the message that it is not a complete URL, add https:// to the front and try again.