Skip to main content
INSTRUMENTS/Network & life← J01 · J03 →
J02

URL inspect

Break a URL into parts, edit the query, and strip utm_-style tracking before copying.

HOW IT WORKS

The parse itself is the browser’s URL interface, because that is the WHATWG algorithm and therefore the definition of what a browser will do with the string. Writing a second parser would only create disagreements with reality. Everything else here exists because the URL interface cannot answer it.

The query is re-parsed here rather than handed to URLSearchParams, which treats ?a and ?a= as the same thing — one has no equals sign, the other an empty value, and some back ends distinguish them — and which cannot tell you a parameter appeared twice. ?id=1&id=2 means different things to different frameworks (first wins, last wins, becomes an array), and collapsing it hides the reason a request behaves oddly. Every pair is kept, in order, duplicates included.

The host appears in two forms, because an internationalised domain has two: the browser connects to the Punycode xn-- form while the address bar shows Unicode. RFC 3492 is implemented here in both directions, and while it is at it the tool flags any label mixing two of the three look-alike alphabets — Latin, Cyrillic, Greek. That is the standard homograph trick: replace the a in apple with a Cyrillic а and no reader can tell.

The tracking-parameter list comes from each ad platform’s own documentation and Firefox’s query-stripping list. Any such list expires: networks add parameters faster than lists are updated, and any site is free to make one of them load-bearing, which is why it is editable on the page. The path, by contrast, is never touched — not re-cased, not reordered, not normalised. /A and /a are different resources, and a cleaner that tidies them breaks links.

LIMITS

  • A string with no scheme is retried with https:// in front, but only when the start already looks like a host name. ht!tp://x does not become https://ht!tp//x, which would parse and would not be what anyone meant; a wrong answer is far worse than an error.
  • The Punycode implementation is RFC 3492 alone, without UTS-46 mapping and normalisation, so it is not full IDNA. It will show you what an xn-- label says and help you spot a mixed-script imposter, but do not use its output as a security decision: a meaningful comparison has to happen after UTS-46.
  • The tracking list is an observation, not a specification. Removing those parameters does not change which page you get, because they identify the click rather than select content — but if a site really does route on utm_source, the cleaned URL breaks. Trust the site’s behaviour over the list.
  • Nothing here is fetched. The tool does not visit the URL, does not follow redirects, and cannot tell you whether the link still works.