URL Parser

Anatomy of a URL

A URL is a structured string with seven well-defined parts (scheme, authority, host, port, path, query, fragment) that you eyeball as one blob. When something is wrong — the wrong parameter, an unexpected port, an extra encoded character — it's much easier to spot in a parsed table than in the raw string. This tool uses the browser's native URL object so the parse exactly matches what JavaScript sees, then breaks each query parameter out so the decoded values are visible alongside the raw form.

Debugging scenarios that bring you here

• Debugging an OAuth callback URL where the state or code parameter looks wrong or is truncated.
• Inspecting a tracking URL (UTM tags, click-tokens, session IDs) and seeing the actual values rather than the encoded blob.
• Confirming a webhook URL parses the way the receiving service expects — particularly the path, scheme, and any query parameters.
• Eyeballing why a deep link works in one app and not another (port? scheme? authority?).
• Checking whether sensitive data is accidentally leaking in query parameters instead of request headers.
• Verifying redirect URLs in authentication flows match your allowlist exactly.

Protocol, host, path, query, hash

• Paste any valid URL into the input field and the tool parses it immediately in your browser.
• The URL is broken into its seven canonical parts: protocol (scheme), host (hostname), port, path, query string, fragment (hash), and computed origin.
• Query parameters are extracted and decoded separately, showing both the raw application/x-www-form-urlencoded form and the decoded human-readable value side by side.
• If a URL is malformed or cannot be parsed as a valid URL, the tool will report an error rather than guessing.
• All parsing is done locally in your browser — nothing is sent to any server.

Encoding, fragments, and repeated keys

• Repeated query keys are real. ?a=1&a=2 is two values for a; tools that read only the first miss data. The parser shows all values per key.
• The fragment never reaches the server. Anything after # stays in the browser. If your backend isn't seeing data you put in the URL, check whether it's actually in the fragment.
• Encoding matters. %20 in a query value decodes to space; + in a query value also decodes to space (per application/x-www-form-urlencoded). The browser's URL.searchParams handles both.
• Default ports don't appear in port. A URL like https://example.com/ has port empty (the default 443 is implied). The same applies to port 80 for http.
• Origin is sometimes "null". For file://, data:, or sandboxed contexts, origin is opaque and shown as the literal string null.
• This is parsing, not validation. A URL can parse cleanly and still be wrong for your application (e.g. wrong host, missing path, scheme not supported).

Boundaries of browser-native parsing

• The tool relies on the browser's built-in URL standard parser, so edge cases or non-standard URL schemes may behave differently in other contexts.
• If your URL contains non-ASCII characters (e.g. emoji, Chinese, accented letters), they will be shown both decoded and in percent-encoded form depending on how they were input.
• Very long URLs may be truncated in display for readability, but the full value is always available for copying.

Walking through a parsed result

Paste https://api.example.com:8443/v2/orders?status=open&page=2#top and it breaks into a table: scheme https, host api.example.com, port 8443, path /v2/orders, query status=open & page=2 (each parameter on its own row), fragment top. The unexpected :8443 or a truncated query value jumps out immediately in the table when it was invisible in the one-line blob.

Decoding, repeated keys, and safe inspection

Does it decode percent-encoded values? Yes — a query value like %40 is shown decoded as @, so you read the real value rather than the escaped form. That's what makes it useful for debugging OAuth state and redirect_uri parameters.

What about repeated query keys? Each occurrence is listed separately — ?tag=a&tag=b shows two tag rows rather than silently keeping only one. Repeated keys are legal and some APIs rely on them, so the parser preserves them all.

Does it fetch the URL? No — it only parses the string. Nothing is requested, so it's safe to inspect signed URLs, webhook endpoints and callbacks with secrets in the query without them leaving your browser.

Can it parse a relative URL? It's built for absolute URLs with a scheme. A bare /path?x=1 has no host or scheme to break out — prepend a dummy origin like https://x to inspect just the path and query.

Common URL pitfalls in production

• Double-encoded values. If a query parameter looks like %2520 instead of %20, it was encoded twice — the % itself got percent-encoded. Paste the URL here to see the decoded value and confirm whether your middleware is encoding on top of an already-encoded string.
• Trailing slashes change routing. /api/users and /api/users/ are different paths. Many frameworks treat them differently, and the parser shows the exact pathname so the mismatch is visible.
• Userinfo in URLs. Credentials in the authority section (https://user:pass@host) are parsed but the password is masked in the output. Don't rely on URL-embedded credentials in production — they end up in logs, referrer headers, and browser history.