Move from message context to an independently verified destination
A link inside a friendly conversation can still lead to an impersonation page, an unexpected download, a misleading redirect or a request for credentials. The answer is not to decide from tone alone or to inspect every suspicious address through more third-party services. Use a five-step link-trust ladder: message context, visible destination, independently reached official destination, requested action, and authentication boundary. At each step choose proceed, verify elsewhere, report, or stop. Never copy passwords, one-time codes, recovery links or private conversation text into a link checker or support message. A useful product design supports the same ladder with clear domains, restrained previews, safe reporting and no pressure to leave the app immediately.
Pause when the message changes the expected task
Regard an unsolicited login, urgent account warning, prize, payment correction, file, extension, QR code or request to move platforms as a new task, even when it appears in an established chat. CISA's phishing guidance highlights unexpected requests, urgent language and suspicious links or attachments, and recommends reporting through trusted routes instead of engaging. Check whether the sender, timing and request fit the conversation, but do not rely on the displayed name or a familiar profile image. A known person's account can also send something they did not intend. If confirmation is appropriate, use a separate channel or a previously saved contact, not the contact detail supplied in the same message.
Read the destination without opening it
Use the app's supported link details or a long-press preview to read the hostname without loading the page. Look for substituted characters, misleading subdomains, shortened links, an IP address, unexpected ports, encoded redirect parameters or a mismatch between visible text and destination. Do not manually edit a suspicious address to make it look right, and do not paste a private invitation or tokenized link into a public scanner because the link itself may grant access. HTTPS and a lock indicator describe the connection, not the owner's honesty; Chrome's help explicitly separates connection security from trust in the site. When the destination claims to be a known service, navigate independently from a saved bookmark, installed app or manually verified official page.
Classify the requested action before continuing
A page that only displays public information differs from one requesting sign-in, a one-time code, recovery action, download, payment, browser permission, profile installation or app sideload. Write the action category before deciding. Authentication should begin from the service's known entry, not from a chat link. NIST describes phishing-resistant protocols as binding authentication to a legitimate verifier or protected channel rather than relying only on human recognition; ordinary passwords and manually entered one-time outputs do not provide that property. Even when an account offers a phishing-resistant method, do not approve an unexpected prompt. Cancel and start again through the official app or bookmark.
Design product controls around destinations, not emotional warnings
A companion app can show the effective hostname next to the link, mark redirects, avoid auto-opening external pages, limit rich previews that fetch private URLs, distinguish downloads from ordinary navigation, and provide a report action that preserves only necessary technical context. It should not declare every external link dangerous or display alarming countdowns. For destinations controlled by the service, use fixed allowlisted routes rather than arbitrary redirect parameters. OWASP's redirect guidance favors mapping safe destinations or strictly validating targets. Reporting should allow a user to exclude conversation content where possible and explain what metadata will be sent. Product controls reduce ambiguity but do not certify every destination; an unknown result remains a reason to use independent navigation.
Use a bounded report-and-recovery sequence
If you did not open the link, report it through the app's current control or the impersonated service's contact reached independently, then remove the message according to the product's options. Record message time, displayed sender, visible hostname and report reference without reproducing private text. If you opened a page but entered nothing, close it, cancel downloads and review browser download and permission state. If you supplied a credential or approved an unexpected authentication prompt, go directly to the real service through a known route, follow its current account-security process, review sessions and replace the affected credential where instructed. Do not continue interacting with the original sender, and do not promise that deleting the message removes copies or server logs.
Test the link-trust ladder with harmless examples
Use a public, non-tokenized official page and a harmless redirect you control only if you are authorized to do so. Confirm how the app displays the full hostname, warns before leaving, handles previews, labels downloads and exposes reporting. Do not create look-alike domains, send deceptive messages to other people or test live malicious URLs. Add a negative test: cancel an external-navigation prompt and verify that no browser tab, download or login prompt remains. Record app version, device, link class, expected surface and observed result. Repeat after the app changes its embedded browser, link-preview behavior, redirect handling or reporting flow. The goal is a predictable decision path, not constant suspicion of normal conversation.
Common questions
Does HTTPS mean a link is legitimate?
No. It protects the connection to a site but does not prove the site is the organization it claims to be.
Should I paste a suspicious link into an online scanner?
Not when it may contain a private invitation, account token or conversation identifier; use the app's reporting route and independent navigation.
What if the link asks me to sign in?
Cancel and open the service from its installed app, saved bookmark or independently verified official page.