URL Parser

Break one address into its components, or a whole list into a table, without fetching anything.

Runs on your deviceDeveloperWorkingNo account needed

What this tool does

URL Parser hands the address to the browser's own URL parser and lays the result out row by row: scheme, username, password, host, port, origin, path, the path split into segments, the raw query string, the number of parameters it carries, and the fragment. Underneath, every query parameter is listed by name and value in the order the address wrote them, so a name that appears twice — tag=fair&tag=organic — produces two rows rather than being quietly collapsed into one.

Two settings change what you see. Percent-decode the values is on by default and applies to the path segments, the username and the parameter values, so coffee%20beans reads as coffee beans; the Path and Query string rows above them always show the address exactly as it was written. Turning the setting off re-encodes each parameter value rather than quoting the original bytes, so a value written with + comes back as %20 — read the Query string row when you need the characters as they were sent. Show the password in the URL is off by default, so credentials embedded in an address stay masked until you ask for them, and the table can be read on a shared screen.

Paste more than one line and the tool changes mode. Each line is parsed on its own and the output becomes a seven-column table — URL, scheme, host, port, path, query, fragment — with any line that will not parse marked invalid instead of stopping the batch. Two differences in that mode are easy to miss: values are shown raw whatever the decode setting says, and the first column echoes each line as you typed it, so a password inside one of those addresses is on screen whether or not the reveal box is ticked.

Nothing is fetched and nothing is uploaded — the work happens in this browser tab, so an address carrying a session token or an internal hostname stays here, and the tool goes on working offline. What it cannot tell you is whether the address resolves, what it answers with, or where it redirects; that would take a request, and this one never makes any. Parsing also normalises as it goes: a line with no scheme is prefixed with https://, the host is lower-cased, an internationalised domain is converted to its xn-- punycode form, and a .. segment is resolved away. A note above the table records the added scheme, but only in the single-address view, so in a pasted batch that assumption is made silently. A non-http scheme such as mailto: still parses, but the host comes back empty and the origin reads null, because there is no authority to report.

How to use it

  1. Paste the URL. One address, or press Load sample for a URL carrying credentials, a non-default port, a repeated parameter and a fragment.
  2. Leave percent-decoding on, or turn it off. Decoded values read like ordinary text; with decoding off the values come back re-escaped, and the Query string row keeps the query verbatim.
  3. Reveal the password only when you need it. Credentials written into an address are masked by default, so the breakdown can be read with someone watching the screen.
  4. Read the parts, or copy them. Copy returns the same rows as plain text, with the query parameters underneath as name = value pairs, ready for a ticket.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

Working out why a link breaks

An unescaped ampersand or a stray colon moves where the query begins. Seeing host, path and parameters separately shows which part the browser actually read.

Checking a callback or redirect target

OAuth flows nest one address inside another. Splitting the outer one names the port, the path and each parameter before you follow anything.

Reading a batch out of a log

A column of addresses becomes a row each, which is enough to spot the one request that went to the wrong host or an unexpected port.

Confirming a port or its default

The port row shows 8443, or names the default — 443 for https, 80 for http — so an unusual-looking address can be settled without guessing.

Questions

Is the URL sent anywhere?
No. Parsing runs in this browser tab using the built-in URL parser, so the address is not transmitted, logged or stored, and the tool still works with the network disconnected.
Does it check that the URL works?
No. It never makes a request, so a dead host, a redirect chain and a 404 all parse the same way. Redirect Checker follows the hops and HTTP Header Inspector reads the response headers.
Why does it say https:// was assumed?
Because the line had no scheme, and one is required before anything can be parsed. The note is printed for a single address only; in a multi-line batch the same assumption is made without a warning, so type http:// explicitly when the scheme is the thing you are checking.
Can it parse URLs in bulk?
Yes. One address per line turns the output into a table of scheme, host, port, path, query and fragment. A line that cannot be read is marked invalid and the rest of the batch still comes back.
Why is my domain shown as xn--something?
The URL standard stores internationalised domains in punycode, so münchen becomes xn--mnchen-3ya. That is the form that travels on the wire; the readable spelling is what a browser puts back in the address bar.
Why is the password masked?
Credentials in an address are hidden until you tick Show the password in the URL. The masking applies to the single-address view only — in the multi-line table each line is echoed exactly as you pasted it.
How is this different from Query String Parser?
URL Parser splits the whole address and lists the parameters flat. Query String Parser takes only the query and expands bracketed keys such as a[b] into nested structure, which is the better fit when the query is the part you care about.

Related tools