URL Parser

A URL is not just text with slashes in it

It is tempting to reach for url.split('/') or a home-grown regular expression, and it works fine right up until a URL has a port, or embedded credentials, or a query parameter that itself contains a slash, or a hostname written in punycode. This page uses the browser's own URL constructor — the same parser that decides where your browser actually navigates — so the breakdown matches what the platform itself considers correct rather than what a hand-written pattern happened to catch.

The WHATWG URL Standard is stricter than most people expect. A default port is dropped — https://api.example:443/ and https://api.example/ parse to the identical hostname and an empty port, because 443 is already what https: means. A non-ASCII hostname is converted to punycode automatically, which is why an internationalised domain someone pasted from a browser address bar can come back looking like xn-- gibberish here — that is correct, not a bug in the parser.

The query part gets the same bracket-aware treatment as the dedicated Query String to JSON page, so nested and repeated parameters come out identically here — this page is really that one plus everything in front of the ?.

Everything happens in your browser. A URL with credentials or a session token embedded in it is exactly the kind of thing that should never touch a server it does not have to.

Breaking down a URL

1. Paste a full address – Copy it from a browser's address bar, a network tab, an API doc, or a redirect chain — anything with a scheme works, and a path-only or relative reference is handled too, see below.
2. Read the breakdown – Scheme, host, port, path, the raw query string, the query parsed into an object, and the fragment, each as its own field rather than one flattened blob.
3. Watch for the grey notes – They cover the parts of the URL standard that most surprise people — a default port that got silently dropped, a hostname written in punycode, or credentials embedded in the URL itself.
4. Pasted something with no scheme? – A bare path like /search?q=1 still parses — the note under the output says it was read as relative, and only the parts that were actually present (path, query, fragment) are shown.

A URL with user:pass@ in it still works, but modern browsers hide that part from the address bar on purpose — it has been a phishing technique for as long as browsers have rendered it, tricking people into reading the part after @ as the whole address. If this page reports a username or password field, that URL is carrying credentials in plain sight.

One address, every part named

A subscriber-usage endpoint with a non-default port, a nested query filter, and a fragment — the kind of URL you actually copy out of a network tab.

https://api.telco.example:8443/v1/subscribers/8901240544102066246/usage?fields%5B%5D=msisdn&roaming=true#latest

{
  "protocol": "https",
  "hostname": "api.telco.example",
  "port": "8443",
  "pathname": "/v1/subscribers/8901240544102066246/usage",
  "searchParams": { "fields": ["msisdn"], "roaming": "true" },
  "hash": "latest"
}

When you need this

Checking where a redirect actually goes

OAuth and SSO flows carry a whole destination URL inside a redirect_uri parameter. Parsing it tells you the real hostname a login is about to send someone to — worth doing on any callback URL you did not write yourself, since a convincing-looking host in the path is not the same as the actual hostname field.

Debugging a port or protocol mismatch

A request failing only in one environment is very often a scheme or port difference — http: versus https:, or a load balancer listening on a port the URL never mentions because it matches the scheme's default. Reading protocol and port as separate fields makes the mismatch obvious instead of buried in one long string.

Pulling apart an API endpoint from documentation

Copy an example URL from a vendor's docs and see the path template and query parameters separated from the host, useful for building the equivalent request in whatever HTTP client you are using.

Spotting a URL with embedded credentials

The ftp://user:password@host/ form still shows up in legacy scripts and old documentation. This page surfaces the username and password fields explicitly rather than leaving them buried in the string, which is usually the fastest way to notice a secret sitting somewhere it should not be.

Getting the query parameters as JSON without a second tool

Skip copying the query string out separately — paste the whole URL here and the searchParams field already has it parsed, with the same nesting rules as Query String to JSON.

What this page does

• Parses with the browser's own URL constructor rather than a hand-written pattern, so edge cases — ports, credentials, punycode hosts — are handled the way the platform actually handles them.
• Parses the query string with the same bracket-aware reader as Query String to JSON, so nested and repeated parameters come out identically.
• Handles a relative reference (a bare path, with no scheme or host) instead of only accepting complete addresses.
• Flags a default port given explicitly, a punycode hostname, and credentials embedded in the URL — the three things about the URL standard people most often get wrong assumptions about.
• Runs entirely in your browser, which matters here specifically — a URL is one of the most common places a secret ends up by accident.

Questions people actually ask

Why is the port field empty when my URL clearly has :443 in it?

Because 443 is the default port for https:, and the URL standard normalises it away — https://api.example:443/ and https://api.example/ are the same URL. The grey note under the output says when this happened, since the character was in your input and it is reasonable to expect it back out.

My hostname turned into xn--something. What happened?

You pasted an internationalised domain name, and the parser converted it to its punycode form — the ASCII-only encoding DNS actually uses under the hood. That is not a bug; it is what your browser's address bar does too, just usually rendered back as the readable form for you afterwards.

Can I parse a URL that does not have http:// on the front?

A bare path like /search?q=cats parses fine and is reported as relative, with only the path, query and fragment shown. A bare hostname with no scheme, like api.example.com/path, does not — it is genuinely ambiguous whether that is a URL missing its scheme or a relative path that happens to have dots in it, and guessing wrong would be worse than asking you to add https://.

Does this validate whether the URL will actually load?

No — it checks the URL is well-formed according to the standard, not that the host is reachable or the path exists. A syntactically valid URL to a server that is down parses here without complaint.

Why does searchParams look different from just decoding the search string?

Because it is parsed with the same bracket-notation reader the rest of this site's URL tools use, so ?tags[]=a&tags[]=b comes back as a real array rather than the flat key-value pairs a simpler decoder would give you. See Query String to JSON for the full explanation of that convention.

Related tools

Specifications and references

• WHATWG URL Standard – The living specification this page's parser implements
• MDN — URL – The constructor and the fields it exposes
• RFC 3986 — Uniform Resource Identifier (URI): Generic Syntax – The older IETF grammar the WHATWG standard supersedes for browsers