URL Parser

What is a URL made of?

A URL is a structured address. Each part is delimited by a specific character, and knowing which delimiter starts which section is most of the knowledge you need:

https://user:pass@api.example.com:8443/v1/tools?q=json&limit=20#results
└─┬─┘   └───┬───┘ └──────┬───────┘ └┬─┘└───┬───┘└──────┬──────┘└──┬──┘
scheme   userinfo      hostname    port   path       query     fragment
                └──────────── host ─────┘
        └───────────────── origin ───────────────┘

Two derived values matter more in practice than any single part.

origin is scheme + host + port. It is the unit the same-origin policy works on, so https://example.com and https://api.example.com are different origins, and so are http://example.com and https://example.com. Every CORS decision comes down to comparing origins.

host versus hostname trips people up constantly: host includes the port, hostname does not. For api.example.com:8443, host is api.example.com:8443 and hostname is api.example.com.

How to parse a URL here

1. Paste a full URL It needs a scheme. Without one, example.com/page is ambiguous — the standard reads it as a relative path, not a hostname.
2. Or paste a relative URL and add a base A path such as /docs?lang=en has no host of its own. Supply a base URL and it is resolved exactly as a browser resolves a link on a page.
3. Read the components table Every property the URL API exposes, each with its own copy button. Any embedded password is reported as present with its length rather than displayed.
4. Compare raw and decoded query values The query table shows both, side by side. That is where percent-encoding problems become visible.

Query parameters: raw versus decoded

Showing both forms is deliberate, because the difference is where most URL bugs live.

Look at rows two and three. In a query string, + means a space, inherited from HTML form encoding — but a literal plus sign must be written %2B. So ?q=1+1 searches for "1 1", not "1+1". URLSearchParams applies this rule correctly; naive decodeURIComponent() on the whole query string does not, which is a common source of mangled search terms.

Row four shows a nested URL. When a whole URL is a parameter value, its own ?, & and / must be percent-encoded, otherwise the outer query string absorbs them. If a redirect after login drops everything after the first &, this is almost always why. The URL Encoder & Decoder handles the encoding side.

Repeated parameters have no single standard

?tag=react&tag=nextjs&tag=css is perfectly legal, and it is the usual way to express a list. What no specification settles is how a server should interpret it, and frameworks genuinely disagree:

This page flags repeated names so you notice them, because a filter that silently keeps only one of three selected tags is a bug that is very easy to miss in testing.

Examples of edge cases worth knowing

The fragment never leaves the browser

Everything after # is processed by the client only. It is not sent in the HTTP request, does not appear in server access logs, and cannot be read by your backend. That is why single-page app routers historically used it, and why a fragment is a poor place to put anything you need server-side.

A default port disappears

Parse https://example.com:443/x and the port property comes back empty. The URL API normalises away the default port for the scheme, so 443 for HTTPS and 80 for HTTP are dropped. The port is shown here as "default for https (443)" rather than blank, so the value is not mistaken for missing information.

Credentials in a URL are a liability

https://user:pass@example.com is syntactically valid and practically a mistake. The credentials travel in browser history, referrer headers, server logs and analytics. Chrome strips them from fetch() requests, and browsers have progressively restricted them because of phishing patterns such as https://your-bank.com@attacker.example, which points at attacker.example. Use an Authorization header instead. This page masks the password rather than displaying it.

Punycode hostnames

A hostname containing non-ASCII characters is stored as Punycode with an xn-- prefix. bücher.example becomes xn--bcher-kva.example. Browsers display the readable form but resolve and transmit the encoded one — which is also the mechanism behind homograph attacks, where Cyrillic characters that look like Latin ones produce a visually identical domain name.

Path segments are individually encoded

Each segment between slashes is encoded separately, so a slash inside a segment value must be written %2F. This page decodes each segment individually, which is the correct way to read them.

Use cases

• Debugging a broken redirect. Parsing the URL shows immediately whether a nested return_to value was encoded properly or was truncated at an &.
• Auditing campaign links. Confirm that every UTM parameter is present, correctly spelled and correctly encoded before a send goes out.
• Diagnosing a CORS failure. Comparing the origins of two URLs makes it obvious whether a mismatch is the scheme, the subdomain or the port.
• Reading a URL from a log line. Long encoded URLs are unreadable inline; the decoded parameter table makes them legible.
• Checking a webhook or callback URL. Verify the path, port and query before registering it with a third-party service.
• Understanding a routing bug. The numbered path segments correspond directly to route parameters in most frameworks.

To go the other way and build a safely encoded URL, use the URL Encoder & Decoder. To turn a captured request into code, the cURL to Fetch Converter handles the whole command.

Privacy and security handling

Parsing uses the browser's built-in URL and URLSearchParams. No request is made to the URL you paste — it is read as text, never fetched — and nothing is uploaded.