URL Parser - Split a URL into Protocol, Host, Port, Path, Query and Fragment

A URL has up to eight parts: scheme://user:password@host:port/path?query#fragment. This tool hands the text to the URL class that your browser provides, which implements the WHATWG URL Standard, so the result matches what a browser does with the same link. Parsing also normalises. The scheme and host are lower-cased, a port equal to the scheme's default is dropped (80 for http, 443 for https, 21 for ftp, 80 for ws and 443 for wss), dot segments such as /a/../b are resolved, and characters that are not allowed are percent-encoded. The Normalised URL box shows that form.

The path is split at each slash and every segment is percent-decoded as UTF-8, so b%20c reads as b c. A segment that contains %2F decodes to something with a slash in it, and the table flags it because that slash is data, not a separator. The query is split at & into parameters in order, and a name that repeats is listed once for each time it appears. In a query + means a space and %XX is a byte, so q=caf%C3%A9+au+lait reads as café au lait. A name such as list[] is shown exactly as written: square brackets mean nothing to the URL standard, they are a convention of frameworks such as PHP and Rails. RFC 3986 says the fragment is separated from the rest of the URI before a request is made and is dealt with by the user agent alone, so a server does not receive it.

A host name written with letters outside ASCII is converted to punycode by the URL parser, so münchen.example becomes xn--mnchen-3ya.example (RFC 3492). The tool decodes any xn-- labels back to Unicode for display. It does not check the result against the full IDNA rules, so treat the Unicode form as a display aid. Look-alike letters from other alphabets can imitate a familiar name, so check any xn-- host you did not type. Addresses written in short forms are normalised as well: http://0x7f.1/ and http://2130706433/ both become 127.0.0.1. RFC 3986 deprecates the user:password form and says that passing authentication information in clear text has proven to be a security risk in almost every case where it has been used. The tool warns when a URL contains them.

A relative reference such as ../images/logo.png or /path?x=1 means nothing alone. Enter a base URL and it is resolved against the base the way a browser resolves a link on a page at that address. A pasted address with no scheme, such as www.example.com/page, is refused by the standard parser. By default the tool reads it as https:// plus the text and says so, and the switch turns that off. A value like localhost:3000/api is a special case, because the standard reads localhost: as a scheme, so the tool adds https:// there too. If a URL is invalid, the tool says why where it can: a space in the host, a port above 65535, an IPv4 address with a part above 255.

Marketing links carry parameters that record where a click came from: the utm_ family from Google Analytics campaign URLs, click IDs such as gclid, fbclid and msclkid, and campaign IDs from email tools. When any are found the tool lists them, and the Remove tracking parameters button writes the URL without them, leaving every other parameter exactly as written. This does not change the page in most cases, but a site can use any parameter name for anything, so check the cleaned link before you share it. The Rebuild form lets you edit the scheme, user, host, port, path, fragment and each parameter and shows the URL that results.