URL Parser

One URL, dissected

Take the example in the box: https://shop.example.com:8080/products/shoes?color=red&size=10&color=blue#reviews. The browser does not see one long string. It sees seven fields, and every one of them changes how a request behaves.

The scheme is https: — note the colon, which the URL standard treats as part of the protocol property. The host is shop.example.com and the port is 8080, which is explicit here because it is not the default 443 for HTTPS. Together with the scheme those three make the origin, https://shop.example.com:8080, and origin is the unit that browsers use for the same-origin policy, cookies scoped by host, and CORS decisions. Change the port and you have a different origin, even on the same machine.

The path is /products/shoes, which splits into two segments: products and shoes. Segments matter because routers match them positionally — an extra trailing segment or a stray double slash quietly produces a 404 that looks identical to a typo. Then the query string carries three pairs, and the fragment is reviews.

Why the encoding toggle exists

A URL can only carry a limited ASCII alphabet, and a handful of those characters are reserved because they act as delimiters. Percent-encoding is how everything else travels: the byte is written as a percent sign plus two hex digits. A space becomes %20 (or a plus sign inside a query string), an ampersand becomes %26, a question mark becomes %3F, a slash inside a value becomes %2F, and non-ASCII text is converted to UTF-8 first, so an e-acute becomes %C3%A9 and an emoji becomes four percent groups.

The practical consequence: ?q=fish%20%26%20chips is one parameter whose value is "fish & chips", while ?q=fish & chips is three broken things. Flip on raw values when you are comparing what a client actually sent against what a server logged; leave it off when you just want to read the data. A common bug is double encoding, where %2520 shows up because a value that already contained %20 was encoded a second time. In decoded view that reads as %20 rather than a space, which is the tell.

The duplicate parameter trap

The example URL contains color twice. This parser refuses to merge them and shows both rows in order, because the correct answer genuinely depends on the receiving stack. PHP keeps the last value unless the key is written color[]. Express and Rails hand you an array. ASP.NET joins them with a comma, producing the string "red,blue". Java servlets expose getParameterValues but getParameter returns only the first. So a link that works in staging can silently pick the wrong colour in production. If you are generating URLs programmatically, deduplicate before you build the query string rather than after.

Everyday debugging workflows

Auditing tracking parameters

Paste a campaign link and look at the parameter table. You will usually find utm_source, utm_medium, utm_campaign, plus platform IDs like gclid, fbclid or msclkid. Those are appended by ad platforms and are invisible to your canonical page, but search engines see them as separate URLs unless a canonical tag says otherwise. Seeing the full list at once is the fastest way to decide which to strip in your analytics configuration.

Fixing canonicals and redirects

Compare the parsed origin and path of the URL a crawler reported against the canonical you intended. Mismatches almost always come from one of four places: an http versus https scheme, a www versus apex host, a trailing slash difference, or an uppercase segment. All four are separate URLs to a crawler even when they render the same page.

Checking what the server can even see

The fragment after the hash never leaves the browser. If a support ticket says "the link with #step=3 does not work", the server logs will show only the path and query, because the browser removed everything from the hash onward before sending the request. Anything the backend must react to belongs in the path or the query string.

Limits worth knowing

This tool uses the same WHATWG parser the browser uses, so its results match what your JavaScript will see — including quirks such as lowercased hostnames, punycode conversion of international domains, and the default port being dropped from the origin. It does not fetch the URL, so it cannot tell you whether the page exists, whether it redirects, or whether the certificate is valid. Very long query strings are parsed fine here, but servers and proxies commonly cap a request line at 4 to 8 KB, so a URL that parses cleanly can still be rejected in transit. And when a scheme is missing, the tool assumes https and says so above the results — useful for pasting a bare domain, but do not read that assumption as a claim that the site supports TLS.