How to Verify a Link Before Clicking It
By cryptoke, developer and editor at SafeLinkWrite. Reviewed for technical accuracy. This is the practical workflow. For the pattern catalogue it references, see Phishing Link Patterns and HTTP vs HTTPS.
Phishing attacks, malware downloads, and abandoned redirects all rely on the same assumption: that most people click links without checking them. That assumption is reasonable. Checking a link takes seconds and most people are in a hurry. The problem is not that the check is hard — it is that the check has no fixed shape. Without a routine, every link requires reinventing the same reasoning under time pressure.
This article gives that check a fixed shape: six steps, run in order, taking a few seconds each. They catch the majority of common link problems — typosquatted domains, mismatch between visible text and destination, unencrypted pages, redirect chains, and suspicious delivery context — without turning every click into a research project. The steps are designed to be memorised once and applied without thinking about the underlying theory.
The Six-Check Routine at a Glance
| # | Check | Time | What it catches |
|---|---|---|---|
| 1 | Read the domain | 2 sec | Typosquatting, homograph, subdomain deception |
| 2 | Hover and compare | 1 sec | Visible-text vs destination mismatch |
| 3 | Check the protocol | 1 sec | Unencrypted pages that can be tampered with |
| 4 | Inspect redirect parameters | 2–5 sec | Open-redirect abuse, hidden destinations |
| 5 | Expand shorteners | 3–10 sec | Obscured final destinations |
| 6 | Judge the source | contextual | Malicious links in plausible-looking contexts |
Steps 1 through 5 apply to any link regardless of where it arrives. Step 6 is contextual and takes longer only when the source itself is unfamiliar. In ordinary use, steps 1 through 3 resolve the decision in under five seconds for the vast majority of ordinary links.
The Six Checks in Detail
1. Read the domain — not the path
The domain is the part of the URL between the protocol and the first single slash. For https://example.com/download/file, the domain is example.com. Everything after the first single slash — the path, the file name, the query parameters — can be added or changed by websites, tracking scripts, and anyone building an interstitial page. It is not part of the address.
Read the domain slowly. Look for misspellings, extra words, and hyphens that mimic a real domain. paypal-secure-login.com is not PayPal. faceb00k.com is not Facebook. If the domain itself does not identify the party you expect to reach, stop here — the remaining checks cannot rescue it. For the full catalogue of domain-level trick patterns, see the phishing patterns guide.
2. Hover before clicking — compare text to destination
On desktop browsers, hovering over a link displays the full destination in the status bar at the bottom of the window. On mobile browsers, holding a link down typically reveals the URL. These gestures show the true destination even when the visible text of the link claims to be something else.
If the displayed destination does not match the text of the link — a link labelled bankofamerica.com that reveals secure-bofa.net on hover — do not click. The mismatch is one of the clearest phishing signals available to an ordinary user.
3. Check the protocol — HTTPS or not
Links beginning with https:// are encrypted. Links beginning with http:// are not. On a public network, an unencrypted page can be modified between the server and the browser before the page finishes loading — including the page itself, not just the request. Modern browsers warn about unencrypted pages in the address bar. Treat those warnings seriously, especially on pages that request any kind of login or personal information. For the full breakdown of what HTTPS does and does not guarantee, see HTTP vs HTTPS.
4. Inspect redirect parameters before you commit
Some links are designed to forward the visitor to another URL. This is common with marketing trackers, URL shorteners, and safelink pages. It is not automatically a problem, but the destination deserves a look.
If a link looks like this:
https://example.com/out?url=https%3A%2F%2Freal-destination.comthe destination can be read directly from the URL. The parameter url= contains the target — human-readable once URL-decoded. Common parameter names to look for: url, link, goto, next, redirect, dest. Decode the value. Is it the domain you expected? If the link goes through a redirect you did not anticipate — even to a legitimate destination — that is itself worth knowing before you click.
5. Expand shorteners before following
For shorteners you do not recognize, paste the URL into a link expander. These tools follow the redirect chain without rendering the destination page. You see the full list of hops without putting your browser in the middle.
If the chain is longer than one or two hops, or if any hop looks suspicious — cross-domain, unfamiliar CDN, unexpected affiliate parameter — do not proceed. A shortener that hides a final destination you would not have clicked directly is doing its job as designed; the check is to refuse that job.
6. Consider the source
Where the link came from matters as much as what the link contains. A link in an email from a supplier you have corresponded with for years is different from a link in a first-message DM from an unknown account. A link in the middle of a well-edited blog post is different from a link in a comment from a user with three followers.
You do not need to distrust everything. You do need to notice when a link appears in an unusual place. Phishing works by placing a plausible-looking link in a plausible-looking context — the context is part of the mechanism, not a coincidence around it.
Example: Running the Routine on a Realistic Link
An email arrives from a supplier you have corresponded with before. The link reads:
<a href="https://supplier-portal-secure.com/inv?url=https%3A%2F%2Finvoice.example.com%2Fpay">
View your invoice
</a>Running the routine:
- Domain:
supplier-portal-secure.com. Not the supplier's real domain — the extra words "portal-secure" are decoration, not ownership. If the supplier's real domain issupplier.com, the domain fails at step 1. - Hover: Would have revealed the same URL. Consistent with the anchor text — but the anchor text itself is the problem ("View your invoice" pointing to a domain that is not
supplier.com). - Protocol: HTTPS. Passes step 3 — but this only confirms the connection is encrypted, not the destination.
- Redirect:
url=https%3A%2F%2Finvoice.example.com%2Fpaydecodes tohttps://invoice.example.com/pay. A different domain from both the wrapper and the supplier. Two hops, two domains — neither of which is the supplier. - Expand: Unnecessary once step 4 failed. The redirect target is already visible.
- Source: The email arrived from an address that looks like the supplier's, but linking rules out the domain failure already.
The check resolves in step 1 — the domain does not match the supplier. Step 4 confirms the second failure. Correct action: do not click. Reach the supplier through an email inbox you already trust, or phone a number you already have.
Myths vs Facts
| Myth | Fact |
|---|---|
| "Checking every link is paranoid." | Steps 1 through 3 take under five seconds and catch the majority of link attacks. Paranoid is the wrong word for a routine that is faster than reading the subject line. |
| "If antivirus is installed, checking is unnecessary." | Antivirus catches known-bad URLs. Newly registered phishing domains and targeted links routinely pass under the radar for the hours before blacklisting. |
| "Mobile is safer because it's harder to click." | Mobile is where URLs are hardest to read. The small address bar and truncated hover gesture make mobile the more forgiving environment for phishing, not the safer one. |
| "The padlock rules out the danger." | The padlock confirms encryption. It says nothing about whether the destination is the one you intended to reach. |
| "If the sender is someone I know, the link is fine." | Sender accounts get compromised. A link from a known contact's account that arrives out of context deserves the same check as a link from a stranger. |
| "Safelinks are pointless because the destination is visible anyway." | The visible destination is the point. Ordinary links only reveal the destination on hover, inspection, or after loading. A safelink displays it before the click is committed — matching the routine's first five checks against what the visitor would otherwise see only afterward. |
Five Rules That Cover the Routine
- Read the domain, not the path. If the domain is wrong, nothing else about the URL matters.
- Hover before clicking — every time. Compare the visible text to the actual destination. Mismatch is a stop signal.
- HTTPS is the baseline, not the verdict. It confirms encryption. It does not confirm intention.
- Decode redirect parameters. Expand shorteners. What the URL turns into matters more than what it looks like.
- If the source is unexpected, the check is more strict — not less. The context is part of the attack.
When in Doubt, Do Not Click
If a link fails any of the checks above and you cannot immediately explain why, do not follow it. Reach the destination by typing the domain manually, opening the official app, or finding the same content through a search engine. The content you are looking for is almost always reachable through a path that does not depend on trusting one suspicious link.
Verifying a link takes a few seconds. Recovering from a mistake can take much longer. The routine is written down so it can be followed without deciding. Run it on the next link that arrives from somewhere unexpected — the domain will tell you, in the first two seconds, whether the rest of the work is worth doing.