URL Parser

Getting More Out of a URL Breakdown

• Check the normalized Href before assuming a URL is exactly what you typed. Browsers lowercase the host and re-encode stray characters automatically — the Href row shows what will actually be requested.
• Use the raw Query String view to catch double-encoding bugs. If a decoded value still contains a stray % or +, the original value was likely encoded twice somewhere upstream.
• Turn on Resolve Relative URLs before pasting a path copied from an HTML href attribute. Most links inside a page are relative, not absolute, and need a base URL to resolve correctly.
• Switch to Bulk Mode for anything more than two or three URLs. Checking a sitemap export or a spreadsheet column one line at a time wastes the exact repetition bulk mode exists to remove.

Features

What Actually Happens When a URL Gets Parsed

A URL looks like one continuous string, but it's actually a strictly defined structure with each piece meaning something specific: a scheme telling the browser which protocol to use, an authority section holding the host and optional port and credentials, a path identifying a resource on that host, an optional query string carrying parameters, and an optional fragment pointing at a location within the page. Parsing takes that one string and splits it back into those named pieces exactly the way a browser or web server does before deciding how to handle the request.

This tool uses the browser's own built-in URL constructor to do that work — the same parsing logic every browser runs internally, defined by the WHATWG URL Living Standard rather than a reimplementation that might disagree with it on an edge case. That's also why the Href field frequently looks slightly different from what was typed: the constructor normalizes the result the same way a browser would before actually sending the request, lowercasing the host, percent-encoding characters that need it, and adding a trailing slash to a bare origin.

Origin and pathname sound similar but answer different questions, and mixing them up causes real bugs — origin is the protocol, host, and port taken together, the exact boundary browsers use to decide whether two pages are allowed to talk to each other under the same-origin policy, while pathname is just the resource path within that origin. Two URLs with identical paths but different ports are different origins entirely as far as cookies, CORS, and local storage are concerned, even though the path looks the same at a glance — a distinction the Components table keeps visually separate rather than folding into one combined field.

That standardization is relatively recent history. Before the WHATWG spec consolidated things, different browsers and server libraries genuinely disagreed on edge cases — how to treat a backslash in a path, what counts as a valid character in a hostname, whether a URL missing a scheme should be treated as relative or simply rejected. A URL that parsed fine in one context and failed in another wasn't unusual. Relying on the same constructor a browser actually runs removes that class of surprise: what parses successfully here is what a real browser will also accept, not an approximation of it.

Two Genuinely Different Views of the Same Query String

A query string like ?tag=sale&tag=new&q=hello%20world can be read two valid ways, and each answers a different question. The raw view shows exactly what's on the wire — still percent-encoded, still carrying a literal + if one is present, unmodified from how it would appear in a server access log or a network request inspector. The decoded view runs the same decoding step a server-side framework applies automatically, turning %20 and + into actual spaces before the application code ever touches the value.

Repeated keys are a related detail worth getting right rather than glossing over: tag=sale&tag=new genuinely means two separate values for the same parameter, not one value that overwrote the other, and plenty of frameworks read it as an array. The editable Query Parameters table keeps every occurrence as its own row for exactly this reason — collapsing duplicate keys down to one would quietly discard real data that a form or API might depend on.

The space character is a small but genuinely confusing example of why raw and decoded aren't interchangeable. Inside a query string, a literal + conventionally means a space — a holdover from the older application/x-www-form-urlencoded format used by HTML forms — while %20 means the same thing in the stricter percent-encoding used elsewhere in a URL. Both decode to an identical space character, but only one of them is correct depending on which part of the URL it appears in — a distinction that's invisible once everything is decoded and only obvious when the raw form is still visible to compare against.

From Inspecting a URL to Building One

Reading a URL's structure is only half the job most people actually need done — the other half is usually constructing a variation of it. The query builder exists for that: add a parameter, rename one, delete one you don't need, and the Rebuilt URL field updates immediately with a correctly percent-encoded result, ready to copy into a test request or a share link without hand-editing a query string and risking a stray unescaped character.

Resolving relative URLs solves a different, equally common problem — a link scraped from a page's HTML, an entry from a robots.txt sitemap reference, or a redirect target logged without its host is frequently just a path, not a full address. Supplying a base URL lets that path resolve the same way a browser would resolve it against the page it was found on, turning an ambiguous fragment into something concrete enough to actually test or follow.

This comes up constantly when reviewing a page's actual HTML rather than the site as rendered — an anchor tag's href attribute, an image's src, a canonical link tag, or a redirect's Location header are all frequently written as relative paths, and confirming exactly where one of them actually points requires knowing the page it was found on, not just the fragment itself. Setting that page as the base URL turns the question "where does this link go" from a manual mental calculation into an instant, verifiable answer.

Bulk mode is aimed at the version of this problem that shows up at scale: a hundred URLs pulled from a crawl, a sitemap export, or a spreadsheet column, each needing the same basic check — is it valid, what host does it point to, how many parameters does it carry. Running that list through in one pass and exporting the result as JSON is considerably faster than parsing each one individually, and it surfaces malformed entries immediately rather than one at a time as they're discovered downstream.

The IDN detection badge earns its place in the same practical category, not as a curiosity. A hostname converted from a non-Latin script into its Punycode form can look almost identical to a legitimate domain at a glance, which is exactly the property lookalike-domain phishing attempts rely on. Flagging that conversion the moment a URL is parsed turns a hostname that would otherwise need a second, deliberate look into something the tool surfaces automatically — useful well beyond casual URL inspection, in any workflow that reviews links from an untrusted source before they're clicked or embedded somewhere else.

Frequently Asked Questions