URL Parser & Dissector

Overview

Dissects any URL into its components - protocol, hostname, port, credentials, path, query string and fragment - using the browser's WHATWG URL parser, with each field click-to-copy and a table of decoded query parameters. Parsing is live, and malformed URLs are reported as invalid rather than silently mangled.

How It Works

Type or paste a URL. Ten component cards update as you type: protocol, hostname, port (shown as (default) when omitted), username and password if present in the URL, pathname, search string, hash, origin and host. Below them, a table lists every query parameter with its key and value, decoded from percent-encoding. A completely invalid URL produces a red Invalid URL card instead of partial nonsense.

Step-by-Step Usage Guide

1. Paste the URL you need to dissect - query strings with encoded values are the most revealing cases.
2. Read the component cards for the pieces you need: hostname for domain checks, pathname for routing, origin for CORS reasoning.
3. Inspect the query parameter table to see exactly what keys and values the server will receive after decoding.
4. Click any card to copy the raw component value for use in code or a test fixture.

Technical Specifications & Standards

Everything comes from the WHATWG URL Standard implementation your browser ships - the same parser behind location and fetch - so the output matches how your own code's new URL() will see the input, which is the point: URL parsing rules genuinely differ between languages and libraries, and anchoring to the platform's parser tells you what a browser will actually do. A few behaviors worth knowing. Port shows (default) when omitted, because the URL API normalizes https://example.com to an empty port string while knowing the scheme's default. Username and password appear only when the URL carries credentials (user:pass@host), a legacy syntax you should be alarmed to see in the wild. The searchParams table is URLSearchParams, which decodes percent-encoding in values - so a=1%20b and a=2 both display as separate rows, and repeated keys appear once per occurrence. The origin card shows the scheme-host-port triple used for same-origin checks. One boundary: the parser validates hard. A URL with an unmatched bracket, bad percent-encoding in the host, or no scheme at all throws, and the tool surfaces that as Invalid URL - matching how your application code would fail on the same string.

Targeted Use Cases

• Debugging a redirect or callback URL by seeing exactly which path and parameters the server will receive.
• Decoding query strings where percent-encoding or + signs make the raw search string hard to read.
• Checking whether a URL carries embedded credentials (user:pass@), which deserve to be removed.
• Comparing what different URL strings yield as origin, when debugging CORS or CSP violations.

Notes & Gotchas

• Treat this parser's output as the browser's truth: if your server-side language parses the same URL differently, that disagreement is the bug to chase.
• Use searchParams-style decoding (what the table shows) when reconstructing parameters - a hand-rolled split on ampersands misses encoded values.
• Be suspicious of any URL that populates the username and password cards; embedded credentials in links are a legacy hazard.
• Remember the fragment (#...) never reaches the server - it stays in the browser, so it belongs in client-side routing logic only.

Frequently Asked Questions