URL Parser

A URL is read left to right by people and by parsers, and the two do not always agree about where the host is. That disagreement is the mechanism behind a whole family of deceptive links, so this page separates the parts and names the ones that are easy to skim past.

Nothing is fetched

The URL is taken apart as a string. No DNS lookup, no request, no reputation check — so pasting a hostile URL here tells nobody you looked at it, and the host is reported exactly as written rather than as resolved.

What gets flagged, and what that means

Embedded credentials. A URL may carry user:password@ before the host. Everything before the @ is userinfo, not the destination — so https://accounts.bank.example@evil.test/ goes to evil.test. Any password is masked in the output rather than echoed back.

A punycode host. A hostname beginning xn-- renders as non-Latin characters in an address bar, so what a reader sees and what resolves are different strings. It is flagged, deliberately not rendered: displaying the Unicode form would mean showing the exact deceptive string the encoding exists to hide.

A bare IP host, a non-default port, plain http, and leftover percent escapes. Each is ordinary in normal use. They are reported because they are the parts of a URL a reader skims, not because their presence proves anything — these are observations, not verdicts.

Repeated query keys

?a=1&a=2 is shown as two entries rather than merged. Which one a server honours varies by framework, and the difference between them is exactly what parameter-pollution behaviour looks like.

https://accounts.bank.example@203.0.113.9:8080/login?next=%2F%2Fevil.test parses to a host of 203.0.113.9, not accounts.bank.example — everything before the @ is userinfo. Four observations follow: credentials, a bare IP, a non-default port, and escapes still in the query.