URL Parser

How it works

1. 01

   Paste a full URL, scheme included. A bare example.com/path is a relative reference and will not parse on its own — the parser is told when that is what happened.

2. 02

   Parsing runs through the WHATWG URL parser built into the browser, so the answer matches what fetch, curl and the address bar see, normalisation and all: lowercased scheme and host, resolved ./ and ../ segments, punycoded international domains, and default ports dropped.

3. 03

   Read the parts list: protocol, credentials, hostname, port, path, query, fragment and origin. A port that was left off is shown as the implied default — 443 for https, 80 for http.

4. 04

   The query table lists one row per parameter in source order, with the raw text and the percent-decoded value side by side. Repeated keys stay on separate rows, which is what URLSearchParams.getAll returns.

5. 05

   Copy any decoded value from its row. Everything runs in the page — the URL is never uploaded, logged or stored, which matters because URLs carry tokens.

The shape of a URL

A URL is a scheme, an optional userinfo pair, a host, an optional port, a path, an optional query and an optional fragment. The query is decoded as application/x-www-form-urlencoded — pairs split on &, key and value split at the first =, + read as a space and %XX read as a byte. That plus-is-a-space rule applies to the QUERY ONLY: a + in a path segment is a literal plus, which is why the path and the query are decoded differently here.

scheme://username:password@hostname:port/path?key=value&key=value#fragment

Use cases

Questions

Why does my URL fail to parse?

It is almost always a missing scheme. new URL() takes an absolute URL; example.com/path is a relative reference and needs a base to resolve against, and there is no sensible base for a paste box. Add https:// and it parses. A space in the host or a stray character in the authority will also fail.

Is the subdomain, domain and TLD split reliable?

No, and this is the one number here not to trust. It is a plain split on dots: the last label is called the TLD, the one before it the domain, everything else the subdomain. That is correct for api.example.com and wrong for shop.example.co.uk, which reports domain "co" and TLD "uk". Getting it right means checking the host against the Public Suffix List, which is a maintained file of every multi-label suffix, and this tool does not ship one.

Why does the port show 443 when I did not type one?

Because that is the port the request will use. The URL Standard strips a default port during parsing, so .port comes back empty for https://example.com and for https://example.com:443 alike. The implied value is shown separately and marked as implied, rather than leaving a blank that reads as "no port".

Why show both the raw and the decoded value?

They are different strings and different things depend on each. A webhook or OAuth signature is computed over the raw query text, so comparing a decoded value against a signed one fails for reasons that are invisible if you only see the decoded form. The decoded value is what the application receives.

What happens to repeated keys?

Each occurrence gets its own row, in source order. Collapsing them would lose data — ?tag=a&tag=b is two values, and URLSearchParams.getAll returns both while get returns only the first.

Is the password really hidden?

It is masked in the parts list only. The URL you pasted is still in the input box, and nothing here is encryption. What is true is that no part of it leaves the browser: there is no request, no logging and no storage in this page.

Does it handle international domains and punycode?

Yes, in the direction the parser goes. An IDN host is converted to its A-label during parsing, so café.example becomes xn--caf-dma.example and that is what the hostname field shows — which is the form that actually goes into the DNS query.