URL Parser
Split any URL into its component parts and list every query parameter with its value decoded, so you can see exactly what a link carries.
How it works
Parsing uses the browser's own URL implementation, so the result matches how a browser or server will actually interpret the address — including the awkward cases around ports, empty paths and repeated parameters.
Query values are shown decoded rather than raw, because a percent-encoded value tells you nothing at a glance. That is what makes a nested redirect URL readable without a second decoding step.
The formula
Structure
protocol://host:port/path?query#fragment
Origin
protocol + host + port — what the same-origin policy compares
Worked examples
| Scenario | Working | Result |
|---|---|---|
| https://x.com:8443/a/b?c=1#top | Parse | Port 8443, 2 path segments, 1 parameter |
| example.com/path | No scheme given | https:// is assumed |
| ?next=https%3A%2F%2Fy.com | Value decoded | next = https://y.com |
When you'd use it
- Reading the UTM parameters on a campaign link
- Checking where a redirect actually sends people
- Debugging an OAuth callback URL
- Confirming a webhook URL has the right path and query
Common questions
What happens with duplicate parameters?
Every occurrence is listed in order, because that is how they arrive. Servers differ on which one wins — some take the first, some the last — so seeing them all is the point.
Why is the port shown as “(default)”?
Because the URL does not state one, so the protocol's default applies — 443 for https, 80 for http. A browser omits the default port when displaying a URL.
Is the URL sent anywhere?
No. Parsing happens in your browser, which matters because URLs frequently carry session tokens and personal data in their query strings.