A URL parser takes a single string and splits it into the pieces that actually control routing, caching, analytics, and access: the scheme, the credentials, the host, the port, the path, the query string, and the fragment. Reading those pieces off by eye works fine for a short marketing link. It stops working the moment the URL carries five tracking parameters, a percent-encoded path segment, and a fragment that a single-page app is using as its own routing layer.
Arb Digital built this parser for the messy links that arrive in real work — a redirect chain pulled from a server log, a campaign URL that somebody hand-edited, an API endpoint pasted out of a bug report. Everything runs in your browser using the same URL parsing engine the browser itself uses, so nothing you paste is transmitted anywhere.
What This URL Parser Does
Paste a URL and the tool returns every component the WHATWG URL standard defines, laid out as a plain-text breakdown you can copy straight into a ticket or a code comment. The result panel highlights the origin — the scheme, host, and port triple that browsers use as the boundary for cookies, storage, and same-origin policy — because that combination is what determines whether two links share a security context, not the domain name alone.
Underneath, four supporting figures give you the details that matter most when debugging: the scheme, the effective port including the implicit default, the number of path segments, and the number of query parameters. The breakdown box lists each query parameter separately with its decoded value, so a parameter containing an encoded ampersand or a plus sign is shown as the value the receiving server will actually see.
If you paste a relative reference such as ../checkout?step=2, fill in the base URL field and the tool resolves it the same way a browser resolves a link in a page. That is the fastest way to check what a relative href in a template will really point at once it is rendered on a given page.
How to Use It
- Paste the URL. Include the scheme (
https://). A bare host such asexample.com/pageis not a valid absolute URL and will be reported as a parse failure, which is itself a useful signal when you are validating stored links. - Add a base URL if the link is relative. Leave the base field empty for absolute URLs; fill it in only when the first field holds a path fragment, a protocol-relative link, or a bare query string.
- Read the origin in the result panel. This is the scheme plus host plus port. Two URLs with different origins cannot share cookies, local storage, or unrestricted fetch access.
- Check the four supporting figures. The effective port and the parameter count are the two that catch the most bugs, particularly on non-standard ports and on links with accidentally duplicated parameters.
- Copy the breakdown with the copy button and paste it into your notes, a pull request, or a message to whoever generated the link.
The Formula / How It's Calculated
There is no arithmetic here, but there is a strict grammar. A URL is defined by the WHATWG URL Standard, which replaced the older RFC 3986 model as the specification browsers actually implement. The generic shape is scheme://username:password@host:port/path?query#fragment, and every part after the scheme is optional.
The parser reads left to right. Everything before the first colon is the scheme, which is lowercased and must start with an ASCII letter. If the scheme is followed by two slashes, an authority section follows: optional credentials ending at an @, then a host, then an optional colon and port. The path runs from the next slash up to the first ? or #. The query runs from ? up to #. Everything after the first # is the fragment, including any further # characters.
The counts in the result panel follow from that split. Path segments are the non-empty pieces between slashes, so /catalog/winter%20boots/ is two segments, not three — the trailing slash produces an empty final segment that carries no name. Query parameters are counted after splitting the query on &, which means a query string with the same key repeated three times counts as three parameters, because that is how a server receiving it will see them.
Origin Is Not the Same Thing as Domain
The most common misreading of a parsed URL is treating the host as the security boundary. It is not. The origin is the scheme, host, and port together, and changing any one of the three creates a different origin. http://app.example.com and https://app.example.com are different origins. So are https://app.example.com and https://app.example.com:8443. So are https://app.example.com and https://api.example.com, despite sharing a registrable domain.
This matters in practice whenever a page suddenly cannot read a cookie, a fetch call starts failing CORS preflight, or a session drops on one subdomain but not another. The first diagnostic step is to parse both URLs and compare origins character by character rather than trusting a visual scan of two long strings. A stray port, an http where you expected https, or a www prefix is easy to miss by eye and immediately obvious in a parsed breakdown.
Origin is also stricter than the cookie Domain rule, which can be scoped to a parent domain and shared across subdomains. Two URLs can share cookies while still having different origins for storage and scripting.
Percent-Encoding: Where Analytics Data Quietly Breaks
Percent-encoding is the rule that any character outside a small safe set is written as % followed by two hex digits of its UTF-8 bytes. A space becomes %20. A slash inside a path segment becomes %2F, which is why %2F and / are not interchangeable: one is data inside a segment, the other is a segment separator.
The query string adds a second, older convention. In application/x-www-form-urlencoded data — the format HTML forms produce and the one most query strings follow — a space may be encoded as + rather than %20. Both appear in the wild, frequently in the same URL. This tool decodes both conventions in the parameter list, so a value written as snow+boots and one written as snow%20boots both display as the same decoded string.
Where this bites is double encoding. A campaign URL that is encoded once when built and encoded again when passed through a redirect service arrives with %2520 in it — the % of the original %20 having itself been encoded as %25. Analytics then records a landing page URL nobody recognises, and reports split one page into two. If a decoded value in the breakdown still contains a visible % followed by hex digits, you are almost certainly looking at double encoding upstream. Our URL encoder and decoder lets you unwrap one layer at a time to confirm it.
Why the Fragment Never Reaches Your Server
The fragment — everything after # — is processed entirely by the client. Browsers strip it before sending the request, so it appears in no access log, no server-side analytics record, and no backend route. A team that puts a campaign identifier after the hash will see it in browser-side tracking and nowhere else, and a team that debugs a route by reading server logs will never see why one visitor landed in a different application state than another.
Single-page applications complicate this by using the fragment as their own routing layer, so /app#/orders/1188 loads a path the server has no knowledge of. Parse a URL like that and the tool reports the path as /app and the fragment as /orders/1188, which is how the request is really split. If a deep link is not working, check whether the identifying part sits in the fragment rather than the path.
Duplicate and Empty Parameters
Nothing in the URL standard forbids repeating a key. ?id=1&id=2 is valid, and how it is interpreted depends entirely on the receiving framework: some take the first occurrence, some take the last, some collect both into an array. The tool lists every occurrence separately rather than collapsing them, because seeing id appear twice is the whole point — that is the bug.
Empty values behave differently again. ?ref= sends the key with an empty string; ?ref sends the key with no value at all. Most frameworks treat these as distinct, and validation code that checks for presence rather than for a non-empty value will accept the second form and then fail further down. Both cases are visible in the breakdown, so you can confirm which one a link is actually carrying before you go looking in application code.
Reading Redirect Chains and Nested URLs
Redirect services, SSO flows, and consent gateways all embed one URL inside another as a parameter value — ?return_to=https%3A%2F%2Fwww.example.com%2Fdashboard%3Ftab%3Dbilling. Reading that by eye is unpleasant and error-prone. Parse the outer URL first, copy the decoded value of the nested parameter from the breakdown, then paste that back into the input and parse it as a URL in its own right. Two passes will unwrap almost any real-world chain.
The same technique exposes open-redirect risk. If a parameter accepts an absolute URL with an arbitrary host, and the application redirects to it without validating the host against an allowlist, that is a redirect vulnerability. Parsing the nested value and reading its host in isolation makes the question concrete: would this host be acceptable as a redirect target? For the security background on why unvalidated redirects matter, the OWASP cheat sheet on unvalidated redirects and forwards is the standard reference.
Internationalised Domains and Punycode
Hosts containing non-ASCII characters are converted to an ASCII form beginning with xn-- before a DNS lookup happens. A host displayed as a non-Latin name in the address bar may be stored, logged, and certificate-matched in its Punycode form. When you parse such a URL here, you see the ASCII form the browser produced, which is the form your server and your logs will contain.
This conversion is also the mechanism behind homograph confusion, where characters from different scripts render almost identically to Latin letters. Comparing the parsed host rather than the rendered one is the reliable check.
Arb Digital's web development team audits URL structure, redirect chains, and parameter handling as part of every build, so tracking stays intact and pages stay indexable.
Web Development Services Talk to Arb DigitalCommon Mistakes to Avoid
- Comparing URLs as plain strings. Parameter order, a trailing slash, and letter case in the host can all differ while the URL points at the same resource. Compare parsed components, not raw text.
- Assuming the host is the security boundary. Scheme and port are part of the origin too, and a mismatch in either breaks cookies and cross-origin requests.
- Encoding a whole URL when only a parameter value needed encoding. This turns the separators into data and produces a link nothing can route.
- Putting tracking data in the fragment. It never reaches the server, so it will be missing from every server-side report.
- Trusting a parameter that contains a URL. Always parse the nested value and check its host before redirecting to it.
Related Free Tools From Arb Digital
Encode or decode a single component with the URL encoder and decoder, build clean campaign links with the UTM builder and score them with the UTM grader, turn a title into a clean path segment with the slug generator, decode the browser string that arrived alongside a request with the user agent parser, and check what a redirect returned with the HTTP status code lookup. The full free online tools hub has the rest.
Frequently Asked Questions
No. Parsing happens entirely in your browser using the built-in URL interface. Nothing is uploaded, logged, or stored, which means internal and staging URLs are safe to paste.
A parsed URL omits the port when it matches the scheme default, which is 443 for HTTPS and 80 for HTTP. This tool shows the effective port separately so the default is always visible.
The query string starts at the question mark and is sent to the server as part of the request. The fragment starts at the hash and is never sent to the server; only the browser and client-side scripts can read it.
Yes, if you supply a base URL in the second field. The tool then resolves the relative reference against that base exactly as a browser resolves a link inside a page.
Query strings often follow form-encoding rules, where a space is written as a plus sign rather than as percent twenty. Both forms are decoded here, so the parameter list shows the value the server will receive.
That usually indicates double encoding, where a URL was encoded twice before being embedded. Decode the value once more to recover the original, and fix the process that encoded it twice.
That is Punycode, the ASCII representation of an internationalised domain name. Browsers convert non-ASCII hosts to this form before DNS resolution, so it is the form your logs and certificates will use.
This tool reports how a browser parses the string you provide. Server frameworks may apply their own additional rules for duplicate or empty parameters.
