ALL DEVELOPER TOOLS56
URL Parser
URL Parser — Every Part of a URL, Decoded
Break a URL into its parts, read the query string as a table, and see exactly what the parser rewrote on the way through.
About URL Parser
The browser's URL parser is not a splitter, it is a normaliser, and the gap between what you paste and what it returns is where a good share of URL bugs live. Hand it HTTP://Example.COM:80/a/../b and it gives back http://example.com/b — scheme and host lower-cased, the default port dropped, the dot segment resolved. Hand it an internationalised hostname and it gives back the xn-- form, because that is what DNS actually resolves. This page runs that same parser and then says what it changed, rather than presenting the result as your input. The query string is a table with the raw and the decoded value side by side. Repeated keys stay repeats: tag=a&tag=b is two rows, because a server that reads the first and a server that reads the last will disagree about that URL, and collapsing the rows hides the disagreement. A value that still holds a percent sequence after one decode was encoded twice — the classic broken-redirect bug — and that is flagged per value. Editing the table rebuilds the URL. A reference that is not a whole URL — an absolute path, a scheme-relative host, a dotted relative path — resolves against a base URL you supply instead of simply being refused. Nothing is fetched: no request, no DNS lookup, no check that the address exists.
Questions
The URL it shows me is not the URL I pasted.
That is the parser, and the page flags it rather than hiding it. The WHATWG URL parser every browser ships normalises as it reads: schemes and hostnames are lower-cased, a default port is dropped, dot segments in the path are resolved, and non-ASCII is escaped. So HTTP://Example.COM:80/a/../b comes back as http://example.com/b. All of that is exactly what a browser would do with the same string, which is why the components below describe the rewritten URL — that is the one a request would actually be made against. The banner shows both so you can see what moved.
My query string has the same key twice and other tools only show one.
This one shows both, in source order, as separate rows. Repeated keys are legal and common — tag=a&tag=b — and servers resolve them differently: Go's Query().Get returns the first, PHP's $_GET keeps the last, and Express with its default parser builds an array. Collapsing the rows would hide precisely the ambiguity you are debugging. The footnote counts how many repeats were kept. Editing the table and rebuilding writes them all back out in order, so a round trip through this page does not silently deduplicate your query string.
What does DOUBLE-ENCODED mean on one of my parameters?
It means the value still contains a percent sequence after being decoded once, which almost always means an already-encoded string was encoded again. A redirect parameter is the usual culprit: https%3A%2F%2Fexample.com is correct, and https%253A%252F%252Fexample.com is that same value run through the encoder twice, so the server decodes it once and gets a literal %3A back. The table shows the once-decoded value with the raw string underneath, so you can see both. The page does not decode a second time on your behalf, because whether that is correct depends on the receiving code.
Why is my hostname full of xn-- gibberish?
Because that is the hostname. An internationalised domain is stored and resolved in Punycode: münchen.de goes on the wire as xn--mnchen-3ya.de, and that ASCII form is what DNS looks up and what a TLS certificate is issued for. The Unicode spelling exists for humans. This page decodes the xn-- labels back and shows both forms, which is the point — two hostnames that look identical in a browser's address bar can have completely different Punycode, and comparing the ASCII form is the only reliable way to catch a lookalike domain.
Does it check whether the URL actually works?
No, and it never contacts the address. This page reads the string and nothing else: no request is made, no DNS lookup happens, no redirect is followed, and no certificate is checked. A URL that parses cleanly here can still be a dead link, a typo, or a host that does not exist. That restriction is deliberate — a HAR file, a support ticket or a log line often carries a URL with a session token in it, and a parser that fetched what you pasted would be handing that token to whoever owns the domain.
Is my file uploaded to a server?
No. Transmute processes everything locally in your browser using JavaScript and WebAssembly. Your files never leave your device — there is no server, no upload, no cloud processing.