Before tapping any link you are not fully sure about, run it through three checks in this order: compare what the link says against where it actually goes, read the real domain in that destination correctly, and weigh the context the link arrived in. None of these three checks proves a link is safe by itself — each one just rules out a specific category of trick, and a link that passes all three has cleared a set of checks that many common scam patterns rely on you skipping. A link can still pass every check here and turn out to be a problem; see the limitations section below for what this routine does not cover.

Check 1 — does the visible text match the real destination?

A link’s visible text and its actual destination are two entirely separate pieces of data, and nothing forces them to match. Text reading “yourbank.com/login” can technically be wired to point anywhere at all — this is completely normal on legitimate sites too, since “click here” style links exist everywhere — but it means the visible words in front of you are not proof of where a tap will actually land.

If the destination shown does not match the organization the message claims to be from, that mismatch alone is a strong reason to stop.

Check 2 — read the domain in the destination correctly

Once you can see the real destination, the next step is identifying which part of it is the actual registrable domain — the part that tells you who controls the address. This is not simply “the last two words before the first slash”: endings like .co.uk or .com.au are themselves two-part public suffixes, so the registrable domain in login.example.co.uk is example.co.uk (three labels), not example.co or just co.uk. See How to Read a URL: Every Part Explained in Plain English for the full explanation of hostname, registrable domain, subdomain, and public suffix, with worked examples across single-label and multi-label endings.

Regardless of the exact rule, watch for these common patterns while reading:

• A familiar brand name placed in the subdomain position, ahead of a domain it does not actually own, such as yourbank.security-check.example — the real domain there is security-check.example.
• A familiar brand name placed in the path instead, such as security-check.example/yourbank/login — same underlying issue, different position.
• Character substitutions that are easy to miss at normal reading speed, covered in full in Lookalike Domains and Homograph Attacks: What to Check.
• An unusual top-level ending for a brand you associate with a specific one — a bank you have only ever seen on a .com address suddenly appearing on .info or .click.

Check 3 — does the context match what you were expecting?

The identical link can be reasonable in one context and worth stopping on in another. A password-reset link is expected immediately after you request one, and out of place if you did not. Run through these questions:

• Did you take an action that would generate this message, or did it arrive with no prompt from you?
• Is the sender’s actual address or phone number one you recognize — not just the display name shown, which can be set to anything?
• Does the message pressure immediate action, or threaten a consequence for waiting?
• Is this the channel this organization normally uses to reach you, or a different one?

A hypothetical example, worked through step by step

The following is a hypothetical scenario, not a real incident, used to illustrate how the three checks fit together. Suppose a text message reads: “Your package could not be delivered. Reschedule here: [link].” Applying the checks: first, preview the link using the method in the table above rather than tapping it directly. Second, read the resulting domain — if it has nothing to do with any delivery company you are actually expecting a package from, that is already a strong signal on its own. Third, consider the context: did you order something you are expecting delivered, and does this message match how that courier normally contacts you? If the answers raise doubts, the safer path is to open the courier’s own app or website directly — reached by typing the address yourself, not through the link — and check tracking there instead.

A decision table for quick reference

When you cannot preview the destination at all

Some contexts do not show a destination before you commit to opening it — certain in-app browsers and QR codes are two common examples. In these cases, avoiding the link entirely and reaching the organization’s site through a bookmark or by typing the address yourself removes the need to evaluate an unpreviewable link at all. For QR codes specifically, see QR Code Scams: How to Scan Codes More Safely.

Failure modes of this routine

It is worth being upfront about where this three-check routine falls short, since no method here is presented as a guarantee.

Each of the three checks has a specific way it can fail to catch a genuinely dangerous link. A domain can be read correctly and still belong to a site that was compromised after registration, or to a newly registered domain that has not yet built any track record either way — reading the domain tells you who nominally controls it, not whether that party’s systems are currently secure. The context check can be defeated by an attacker who has compromised a real contact’s account or a real company’s mailing list, since the message will then arrive through a channel and timing that looks entirely normal. And link-preview mechanisms themselves are not universal — some apps and some older browser versions do not support hover or long-press previews consistently.

Safe alternative when you remain unsure

When a link fails any of the checks above, or you simply cannot tell, a reliable fallback is not clicking it at all: navigate to the organization’s site directly through a bookmark you already trust, or by typing the address yourself, and find the relevant page or account section from there. This sidesteps the need to fully resolve every ambiguous case.

Frequently asked questions

Is simply loading a page riskier than not clicking at all?

Loading a page is generally lower risk than entering information on it, but it is not risk-free — outdated, unpatched browsers have historically been vulnerable to some automated exploitation just from loading malicious content. Keeping your browser updated is a relevant precaution independent of link-checking habits.

What if the link came from someone I know?

Compromised accounts are common, and a link sent from a hijacked but genuine account looks identical to one sent by that person deliberately. If a link from a known contact seems out of character, confirming through a separate channel — a call or a message on a different platform — is more reliable than trusting the thread it arrived in.

If I already clicked something suspicious, what should I do?

See What to Do After Clicking a Suspicious Link for an ordered set of recovery steps depending on what happened after the click.

Sources and further reading

• CISA: Avoiding Social Engineering and Phishing Attacks
• FTC Consumer Advice: How To Recognize and Avoid Phishing Scams