The most convincing phishing links rarely rely on an obviously wrong domain — they rely on a handful of well-documented techniques that make a malicious URL visually indistinguishable from a legitimate one at a glance, each targeting a different part of how URLs are parsed and displayed. Understanding which technique is in play is what separates 'this looks a little off' from being able to say exactly why.
Homograph attacks substitute visually similar characters from a different Unicode block for the ones in a trusted domain name — a Cyrillic 'а' for a Latin 'a', for instance — and because domains can only contain ASCII, the substituted domain is actually transmitted as punycode (an xn-- prefixed encoding) and only rendered back to its Unicode form by the browser's address bar. The userinfo-segment trick is a completely different mechanism: putting a trusted-looking string before an @ symbol, like https://paypal.com@evil.example/, where everything before the @ is authentication info for the URL and the real host is everything after it — the trusted-looking text is real, it's just not the destination.
These techniques are frequently layered — a userinfo segment containing a familiar brand name, pointing at a punycode-encoded homograph domain, wrapped in a shortened or percent-encoded redirect link — specifically because each individual layer defeats a different, narrower kind of automated or human check, and stacking them buys more plausibility than any single trick alone.
This checker parses the URL into its real components (correctly separating userinfo from host), decodes any punycode labels back to Unicode, and cross-references the decoded hostname against a confusables table — surfacing the actual destination and every obfuscation technique detected, rather than the visual impression the link is designed to create.
Edge cases worth knowing
- A userinfo segment combined with a punycode homograph host
- The example above stacks both techniques: secure-login.xn--80ak6aa92e.com looks like a subdomain but is actually the userinfo segment, and the real host is evil.example. This checker flags both the userinfo trick and, separately, decodes the punycode portion to show what it actually represents even though it isn't the true host in this particular case.
- A legitimate shortened URL with no obfuscation at all
- Most shortened links (bit.ly, t.co, and similar) are used for entirely ordinary reasons and resolve to unremarkable destinations. This checker reports what it can determine from the URL's static structure — it doesn't and can't follow redirects, since that would require making a network request, which conflicts with the fully client-side, nothing-ever-transmitted design of every tool on this site.
- A confusable character in the path or query string rather than the hostname
- Homograph substitution in the path (not the host) doesn't change where the browser navigates, since only the hostname resolves via DNS — but it's still worth flagging, since a convincing-looking path can be part of a social-engineering pretext even when the actual destination is already obviously suspicious.
Common mistakes
- Reading a URL by scanning left to right for a recognizable brand name instead of identifying which part is actually the host.
- Assuming a padlock icon or https:// scheme vouches for a domain's legitimacy — it only confirms the connection to whatever the host is, is encrypted.
- Clicking through a shortened or redirect-wrapped link on the assumption that the visible display text describes the actual destination.
- Treating an xn-- prefixed domain as automatically malicious, when the encoding itself is a standard mechanism used by many legitimate non-English domains — context and confusable-character overlap with a known brand are what actually matter.