URL Parser

How to Use the URL Parser

1. Paste a URL into the input area. The parser is forgiving: schemes are optional (it will prepend https://), query strings can be percent-encoded, and userinfo (user:password@host) is recognised.
2. Inspect the structural fields. The fields table breaks the URL into protocol, origin, hostname, port, pathname, search, hash, and full URL. Each field has its own copy button so you can grab one without selecting around the others.
3. Read the query parameters. The parser decodes the query string and renders it as a key/value table. Duplicate keys are preserved and shown as separate rows, just like the URL standard specifies.
4. Browse path segments. Hierarchical pathnames are split on "/" and shown as a numbered list, which is useful when reasoning about REST route matchers.
5. Copy the whole result as JSON when you need to paste a parsed URL into an issue tracker, a code review comment, or a test fixture. The JSON output collapses duplicate query parameters to a single key for compatibility with standard JSON consumers.

What the Parser Is Actually Doing

The implementation is a thin wrapper around the WHATWG URL constructor. The browser's built-in new URL(input) implements the WHATWG URL Standard - the same parser that all major browsers use for <a href> resolution, the fetch() API, and Service Worker route matching. Calling it from the page gives you exactly the same parse result your application code would see, which matters when you are debugging "why does my route not match" issues. The parser then reads the structural properties (protocol, host, hostname, port, pathname, search, hash, origin, username, password) and renders them in a table. The query string is iterated with URLSearchParams to give you a row per key-value pair, preserving duplicate keys and original order. There is no regex involved and no custom parsing - we lean on the browser's built-in implementation because it is the authoritative specification and because regex-based URL parsers are a well-known anti-pattern (see Jeff Atwood's "The Problem With URLs" if you have not before).

Why a Browser-Based URL Parser Is Useful

The most common reason people reach for a URL parser is debugging routing. A request behaves differently from what you expected, the URL looks fine on the surface, and you need to see what the server is actually going to receive. Pasting the URL into the parser shows you the normalised pathname (with the implicit trailing "/" the browser would add), the actual decoded query parameters, and the hash that never reaches the server in the first place. Another common use is auditing analytics URLs - marketing teams often produce URLs with chains of UTM parameters, sometimes with overlapping utm_content values from different sources, and the per-parameter table makes the overlap visible. A third case is debugging OAuth and SSO redirects, where the state, code, and nonce parameters carry security-relevant information and need to be inspected before being copy-pasted into a bug report.

Privacy and Security

The parser runs entirely in your browser. There is no fetch, no telemetry on the parse path, and no copy of the URL is retained after you navigate away. This matters because URLs commonly contain sensitive material: one-time login tokens in ?code=... parameters, signed redirect URLs with HMAC signatures, Cloudflare R2 or S3 presigned URLs that expose the secret as part of the query string, and OAuth callback URLs with refresh tokens. Pasting any of those into a hosted "online URL parser" is a real risk because most such services log queries for analytics. By running locally we sidestep that risk: even if the entire ZeroUtil site went offline tomorrow, the parser would keep working on already-loaded pages because the URL standard is part of the browser, not a server-side service. The password field is also redacted in the view to make screen-sharing the parsed result safer.

Common Pitfalls When Reasoning About URLs

• Forgetting that the hash does not reach the server. Everything after the "#" stays in the browser. If you put a token there for "stealth", the token is still in the address bar but it never makes it into your server logs. That is sometimes useful (OAuth implicit flow) and sometimes a footgun (you cannot read it from server-side rendering).
• Treating query parameter order as semantic. Many APIs treat ?a=1&b=2 and ?b=2&a=1 as equivalent. CDN caching keys, however, can be sensitive to order - inspect with the parser to see the order your URL actually carries.
• Assuming a single value per query key. ?tag=a&tag=b is two values. URLSearchParams.get() returns the first; URLSearchParams.getAll() returns both. If your framework only uses get(), the second value is silently dropped. The parser shows both rows so you spot the issue.
• Parsing URLs with regex. Real-world URLs include percent-encoded bytes, IPv6 hosts with brackets, userinfo, unusual schemes, and trailing dots in hostnames. Regex-based URL extraction tends to break on every one of those. Use a real parser.
• Trusting the displayed hostname for security decisions. Browsers normalise IDN homograph attacks (xn--... punycode), but if you copy the rendered version out of context you can be deceived. The parser shows the canonical normalised hostname for security review.

Companion Tools

Once the URL is parsed, the next step usually involves one of a handful of nearby tools. The URL Encoder / Decoder handles percent-encoding both ways - useful when you need to write a value into a query string or read out a raw encoded blob. The Bulk URL Encoder / Decoder does the same for many URLs at once, which is handy for SEO audits. The Regex Tester is the right place to design a robust URL-extraction pattern for log scraping (and to talk yourself out of doing it with regex). For inspecting a URL that ends up in JSON, the JSON Formatter shows the surrounding payload with the URL in context. Together they form a small cluster of tools that cover the "see a URL, understand it, transform it, surround it with metadata" lifecycle.

URL Standards and Spec References

The WHATWG URL Living Standard is the current authority on URL parsing. It supersedes RFC 3986 (still useful as a high-level overview) and aligns with how browsers actually behave - which is what matters in practice. The standard defines normalisation rules (lowercase the scheme and the host, percent-decode unreserved characters, collapse dot segments in the path), error-handling behaviour (lenient with whitespace, strict with control characters), and the structural fields the URL object exposes. Reading the spec is heavy going but worth knowing exists; for day-to-day debugging this parser plus a working knowledge of the field names is enough.