URL Parser / Inspector

Parse an absolute URL with the browser URL API, inspect normalized parts, and review decoded query parameters locally.

URL input

Absolute URLs only

This inspector uses the browser URL constructor without a base URL. Relative inputs like /docs are rejected on purpose so parsing behavior stays explicit.

URL Parser / Inspector: Break Down a URL Without Guessing

This URL parser lets you inspect URL parts in the browser and see how a full address is actually interpreted. Paste https://user:pass@example.com:8443/docs/index.html?tab=api&lang=en#intro and the tool can split it into protocol, authority, hostname, port, path, query, and hash in one pass. When you need to parse URL online without sending internal links, signed URLs, or copied production data to a server, local inspection is the right default.

That matters because URLs look simple until they are not. A missing scheme changes how the string resolves. %2F inside a query value is not the same thing as / in a path. example.com:443 may normalize differently depending on the parser. Credentials, IPv6 hosts, repeated query parameters, and fragments all create edge cases that are easy to miss when you are only eyeballing the string.

This tool is useful as both a URL inspector and a URL breakdown reference. You can inspect URL parts quickly, verify browser parsing behavior, and check how query parameters decode before that value gets fed into routing, redirects, fetch requests, or backend validation. Query values are decoded with browser URLSearchParams behavior, including forgiving handling of malformed percent escapes, so the displayed values match what the platform accepts.

What this URL parser shows

A URL parser is not just a string splitter. In browser environments, parsing usually follows the platform URL implementation, which applies normalization rules while keeping the important structural pieces separate.

For a URL like https://example.com:443/a/b?x=1&x=2#top, the breakdown usually looks like this:

protocol: https:
hostname: example.com
port: empty after normalization if the default port is implied
pathname: /a/b
search: ?x=1&x=2
hash: #top

That distinction is useful when debugging link generation, redirect handling, or frontend state encoded into the URL. A URL inspector helps you see which characters are structural and which are data.

Using it

Paste a full URL into the input and review each parsed field. Check the protocol, host, port, path, query string, and fragment separately, then inspect decoded query parameters if you need to verify values like redirect=%2Fdashboard%3Ftab%3Dbilling.

If the input is absolute, browser parsing behavior is usually predictable. If the input is relative, parsing depends on a base URL. That is not a tool limitation; it is part of how URL resolution works. A relative path like /docs/getting-started is valid in context, but it is not a complete absolute URL by itself.

Common reasons to inspect URL parts

Debug redirect and callback URLs before wiring them into auth flows
Check whether a copied link includes credentials, a non-default port, or an unexpected fragment
Break down query strings with repeated parameters like tag=js&tag=ts
Verify whether %20, %2B, %2F, or Unicode characters decode the way you expect
Compare a raw pasted URL with the normalized browser representation
Confirm whether a route bug comes from the path, search params, or hash rather than the whole string

Absolute URLs, relative URLs, and base resolution

Be careful with claims like "invalid URL" when the input is relative. https://example.com/docs is absolute because it includes a scheme and authority. /docs, ../images/logo.svg, and ?tab=settings are relative references. They need a base URL to become fully resolved.

In JavaScript, this works:

new URL("../api/users", "https://example.com/app/dashboard/");
// https://example.com/app/api/users

This does not:

new URL("../api/users");
// throws without a base URL

An honest URL parser should surface that difference clearly. Relative inputs are valid references, but they are not self-contained absolute URLs.

Browser normalization is real

A URL inspector is also a normalization checker. Browsers may lowercase hostnames, remove default ports, resolve dot segments, and percent-encode characters when producing the serialized URL. For example, HTTP://EXAMPLE.COM:80/a/../b may serialize closer to http://example.com/b depending on the parser and context.

That does not mean the original string was useless. It means the parser converted it into a canonical browser-friendly form. If you are comparing URLs in tests, signatures, redirects, or cache keys, normalization behavior matters as much as the raw input.

Query strings, fragments, and what gets sent

The query string is part of the request URL. The fragment is not. In https://example.com/docs?q=url#section-2, ?q=url is sent to the server, but #section-2 stays in the browser.

This is why an inspect URL parts tool is handy when debugging analytics, routing, or anchor navigation. If something only exists after #, your backend never sees it. If it sits in search, it is part of the actual request target.

Troubleshooting

Why won't this relative path parse as a full URL? — Relative references like /settings or ../api need a base URL. They are valid in context, but they are not absolute URLs on their own.

Why did the port disappear from the parsed output? — Browsers often normalize default ports away. :80 for http: and :443 for https: may be omitted in the serialized form even if they were present in the input.

Why did the hostname change case? — Hostnames are case-insensitive, so browser parsers usually normalize them to lowercase.

Why is the fragment not included in my request debugging? — The hash portion after # stays client-side and is not sent in normal HTTP requests.

Why do encoded characters still appear in some fields? — Some characters remain percent-encoded depending on context and serialization rules. A parser may decode query parameter values for inspection while preserving encoded form in the raw URL fields.