URL Parser

Where this actually earns its keep in ASP.NET Core work

The case I reach for this most isn't generic "what's a URL" curiosity — it's a malformed OAuth callback URL, or a webhook payload that includes a redirect target buried three query parameters deep. Pasting the full URL here and getting scheme, host, path, every query key/value pair, and the fragment broken out separately is faster than mentally parsing a 200-character query string by eye, especially when the value you actually care about is URL-encoded inside another URL-encoded value (a redirect URL passed as a query parameter on another URL — common in SSO and OAuth flows).

What "absolute URL required" actually means here

This parser calls .NET's Uri.TryCreate with UriKind.Absolute — it will not accept a path-only string like /api/users?id=5, even though that's a perfectly valid relative URL in an HTTP request. If you're trying to inspect a relative path captured from a request log or an HttpContext.Request.Path value, prepend a placeholder scheme and host (https://placeholder.local) before pasting it in, then ignore the host/scheme fields in the result.

How to use this tool

1. Paste any URL into the input field.
2. Click Parse.
3. View each component — scheme, host, path, query parameters, and fragment — broken out separately.
4. Copy any individual component.

Scheme, host, and path aren't the whole story for routing

When you're debugging an ASP.NET Core route that isn't matching the way you expect, the path this tool shows is exactly what HttpContext.Request.Path sees on the server — but the query string and fragment are not. The fragment (anything after #) is a browser-only concept; it's never transmitted to the server at all, which is why frameworks that do client-side routing off the fragment (older single-page apps using hash-based routing) need JavaScript to read it, not server-side route matching. If a "route" only seems to work when JavaScript runs and breaks on a direct server hit, check whether the part that's supposed to drive routing is actually in the fragment rather than the path.

Two things worth knowing about how parameters are parsed

This parser decodes percent-encoded characters (%20, %2F, etc.) in keys and values, but it does not treat a literal + as a space — that's a form-encoding convention (application/x-www-form-urlencoded), not something Uri.UnescapeDataString does. You can see this in the default example above: q=hello+world parses to the value hello+world, plus sign and all, not hello world. If a URL came from an HTML form submission, you may need to manually replace + with a space afterward.

Also, a query parameter with no = — a bare flag like ?debug or ?verbose — is silently dropped from the parameters table entirely, rather than showing up with an empty value. If you're parsing a URL with flag-style parameters and one seems to have vanished, this is why.

The default port field is empty more often than you'd expect

The Port field only shows a value for non-default ports. https://example.com parses with an empty port field, not 443 — same for plain HTTP on port 80. .NET's Uri.IsDefaultPort check treats the scheme's standard port as implicit, so it only surfaces a port number when the URL explicitly uses a non-standard one, like a local dev server on :5298 or a custom API gateway port. If the Port field is blank, that doesn't mean the URL has no port — it means the URL is using its scheme's default.