Phishing URL signals
The strongest phishing clues usually come from combinations: an unexpected message, a hostname that does not belong to the claimed service, credential or payment pressure, and redirects to an unfamiliar destination. HTTPS or a professional-looking page does not prove legitimacy.
- Read the hostname, not just the words around it.
- Urgency and account language are contextual clues, not proof by themselves.
- HTTPS encrypts a connection; it does not authenticate the sender's story.
- Unexpected requests for credentials or payment deserve independent verification.
Start with the hostname
The hostname is the part of a web address that identifies the destination host. Attackers can place trusted-looking words in subdomains, paths or query parameters, so the presence of a brand name somewhere in the URL is not enough.
More detail
A practical check is to identify the registrable domain you are actually visiting and compare it with the official domain you expected. Can I Share This? also flags some cases where a recognizable brand name appears in a hostname that is not one of the service's recognized domains.
Lookalikes, punycode and visual confusion
Internationalized Domain Names are legitimate and allow domain names in many languages and scripts. Browsers may represent some of them in an ASCII form beginning with xn--, commonly called punycode.
More detail
Because different characters can look similar, internationalized names can also be abused for visual impersonation. Punycode is therefore a reason to inspect a hostname carefully, not evidence that every internationalized domain is malicious.
Account, login and payment wording
Phishing campaigns often use words associated with login, verification, security, billing, delivery, password resets or account suspension. Those terms can also appear on legitimate sites.
More detail
The useful question is whether the language matches the surrounding context. A cluster of high-pressure account terms on an unfamiliar hostname is more concerning than a single word such as login on a known service.
Short links and redirects can hide context
A shortened link prevents the recipient from seeing the destination directly. Redirect chains can also move the browser from a familiar-looking domain to another host before a form or download appears.
More detail
Can I Share This? resolves supported short links and tracks redirect behavior so the final destination can be evaluated. A redirect is not malicious by default, but a surprising destination change should be explained before credentials are entered.
HTTPS is necessary but not sufficient
HTTPS protects the connection between the browser and the site. It does not establish that the site belongs to the organization named in a message. A phishing operator can obtain HTTPS for a domain they control.
More detail
Treat HTTPS as transport security, not a trust badge. Domain identity, context and the sensitivity of the requested action still matter.
What to do when several signals line up
Do not sign in through the message. Open the official app or type a known official address independently. If the message came from a colleague or company, verify the request through a separate trusted channel.
More detail
CISA advises users to be cautious with unexpected messages and suspicious links and to verify before interacting. A scanner supports that decision; it does not replace it.
Primary references
These references define or document the web and security concepts discussed above.
Related reference pages
Check a suspicious link
Use the scanner to inspect the URL, redirects and final destination before you open it.