Where Does This Link Really Go?

Look at this URL: аpple.com. Looks fine, right? Now look at this one: apple.com. They’re different. The first one uses a Cyrillic “а” — the exact same shape as a Latin “a” in most fonts, but a completely different character to a browser. If you typed that first URL, or clicked a link pointing at it, you’d land on a server an attacker controls. The domain is registered. The site is live. The padlock is green. Everything “looks right” — because it was engineered to. This lesson is about URLs that aren’t what they appear to be.

The URL you see isn’t always the URL you’ll visit.

Every piece of scam-awareness training tells you to “check the URL before you click.” That advice assumes the URL on your screen is the URL your browser would actually resolve. Most of the time, it is. But the cases where it isn’t are precisely the cases that matter — the ones you’d never catch by reading, because they’re designed to defeat reading. What follows is how those cases work and how to pull the real destination out regardless.

Homograph Attacks

A homograph attack exploits the fact that many Unicode characters look identical (or near-identical) to Latin letters when rendered in a typical font. Cyrillic lowercase “а”, “е”, “о”, “р”, “с”, and “х” all have visual twins in the Latin alphabet. Greek adds “ο” and “α”. An attacker registers a domain that uses one of these lookalikes in place of its Latin counterpart — аpple.com with a Cyrillic “а”, pаypal.com with the same substitution, goоgle.com with a Cyrillic “о” — and the rendered domain name is visually indistinguishable from the legitimate one.

Modern browsers fight back with an encoding called punycode, which converts non-Latin Unicode in domain names into a Latin-only form that starts with the prefix xn--. In Chrome’s address bar, for example, a mixed-script domain often gets shown as xn--pple-43d.com instead of the pretty Unicode version, so the deception becomes visible. But the protection isn’t universal. Not every mail client converts — some render the Unicode as-is in the link preview. And the moment you copy a homograph URL and paste it into a non-browser context (a chat message, a document, a shared note), it stays visually deceptive.

How to detect one reliably: copy the URL and paste it somewhere that will expose the underlying characters. A plain text file, a URL inspector, or a terminal. If the URL transforms into xn-- anything, or if individual characters “look wrong” when examined next to their Latin counterparts, you’re looking at a homograph.

Punycode in Plain English

When you see a URL that starts with xn-- (or contains that prefix in a subdomain), the address contains Unicode characters that have been translated into a Latin-only encoding so that DNS and older systems can handle them. xn--apple-12a.com is a real domain — it just has a non-Latin character in its original form.

Not every xn-- URL is malicious. Legitimate internationalized domain names use them too — a Japanese business with a Japanese-character domain will show up as xn-- in contexts that don’t render Unicode. But an xn-- URL that claims to be from a major brand like Apple, PayPal, Google, or your bank is almost certainly a homograph attack. The legitimate version of those brands owns the Latin domain outright.

Redirect Chains

A URL doesn’t have to go directly where it says. It can bounce through multiple hops before landing somewhere entirely different. A short link like bit.ly/abc123 might redirect to t.co/xyz, which redirects to tinyurl.com/def, which finally redirects to the actual target — a credential-harvesting page hosted on a throwaway domain. Each hop can be a different service, and each hop can be swapped out by the attacker after the message has been sent. The short link is stable; what it points to isn’t.

The last hop is what matters. Everything before it is misdirection. To see the last hop without clicking, use an unshortener: unshorten.it, checkshorturl.com, or wheregoes.com. Paste the short URL into the tool’s input field. The service follows the redirect chain on your behalf and reports back with the final destination and every intermediate hop. In the case of wheregoes.com, you’ll see a numbered list — hop 1 is the short link, hops 2 through 5 are the redirects, and the last entry is the actual landing page. That’s the URL you evaluate.

URL Obfuscation Patterns

Beyond homographs and redirects, there are a handful of tricks that bury the real destination inside a URL that looks reassuring. Watch for:

• Subdomain lies: paypal.com.evil-host.io — the real domain is evil-host.io, and paypal.com is just a subdomain the attacker added. Read domains right-to-left: the second-to-last dot-delimited segment and whatever follows it is the real owner.
• URL-encoded characters: %40 is the URL-encoded form of @. A URL like https://legit.com%40evil.com/ looks like it starts with legit.com, but the %40 is interpreted as an @ and everything before it becomes a username, not a hostname.
• @ symbol abuse: https://legit.com@evil.com/ — everything before the @ is treated as authentication credentials by browsers and silently discarded. The real destination is evil.com.
• Open redirects on trusted domains: https://google.com/url?q=https://evil.com uses Google’s own redirect endpoint as a stepping stone. The browser follows Google, then follows Google’s redirect to the attacker’s site. The URL passes a naive “is this domain trustworthy?” check because the first hop genuinely is Google.

Your Rule of Thumb

If a URL is plausible, copy it and paste it into a plain text file. If individual characters look off, or the URL expands to include xn--, you’ve got a homograph. If the URL is a short link, run it through an unshortener. If the URL has an @ in it, or a %40, or a suspicious subdomain structure, read it right-to-left and identify the real owning domain. And if any of that leaves you still uncertain, don’t debate the URL with yourself — hand it to a sandbox (Lesson 4.3) and let a tool open it in a safe environment.

Key Takeaways

1. Homograph attacks substitute Unicode lookalikes (Cyrillic/Greek characters) for Latin letters in domain names. аpple.com with a Cyrillic “а” is not apple.com.
2. Punycode (xn--...) is how browsers expose non-Latin Unicode in a domain. xn-- in a URL claiming to be a major brand is a near-certain red flag.
3. Redirect chains hide the real destination behind one or more intermediate hops. Unshortener services (unshorten.it, wheregoes.com) follow the chain for you.
4. Obfuscation patterns — subdomain lies, %40/@ tricks, and open redirects on trusted domains — all make a URL look legitimate while pointing elsewhere. Read domains right-to-left; everything before an @ is authentication, not hostname.