How to check if a link is safe before you click

Most malicious links give themselves away in the text of the link itself, before you ever open them: a host that is really a bare IP address, letters that look Latin but aren't, an @ hiding the real destination, a stack of subdomains impersonating your bank. Learning to read a URL takes about five minutes and defuses the bulk of everyday phishing. The Docuboxer URL inspector does the parsing for you and flags those signals without visiting the link — everything runs in your browser. One caveat up front, because it matters: no local checker can hand you a verdict. "No signals found" is not the same as "safe".

First: find the real domain

Almost every URL trick works by putting a trusted name somewhere it has no authority. To avoid falling for it, you need to know which part of the address decides where you actually connect. Take this one:

https://account.chase.com.secure-verify.xyz/signin?ref=93

Read it like this. Everything between // and the first slash is the host, and only the host determines your destination. Inside the host, the registered domain is the last two labels — here, secure-verify.xyz. Everything to the left of it (account, chase, com) is a subdomain, and whoever owns secure-verify.xyz can create as many of those as they like, instantly and for free. Nothing after the first slash — path, query string, fragment — changes which server answers.

Hence the rule that settles most cases in seconds: find the first slash after //, back up two labels, and read that name. If it isn't the company you thought you were visiting, you're done.

The signals that give a link away

1. The host is an IP address

http://203.0.113.45/usps/tracking has no domain at all — it connects straight to a machine. Real services use names because names are what can be verified, certificated and reputation-tracked; a naked IP has none of that and usually means throwaway infrastructure. The same applies to bracketed IPv6 hosts and to obfuscated forms (the address written in decimal or hex), which exist precisely so you won't recognize it as an IP.

2. Letters that aren't the letters you think

Domain names can contain non-Latin characters, and plenty of alphabets have glyphs identical to ours. Cyrillic а (U+0430) renders exactly like Latin a, so аpple.com and apple.com look like the same string and are two unrelated domains. That's a homograph attack. Underneath, browsers store internationalized names as punycode: аpple.com is really xn--pple-43d.com, where the disguise falls apart on sight. The strong signal isn't punycode by itself — plenty of legitimate international domains use it — but a single name that mixes alphabets. Latin and Cyrillic inside one word does not happen by accident.

3. The @ trick

URL syntax allows a username and password before the host: https://user:pass@server.com/. Browsers ignore everything before the @ when deciding where to connect. That turns this into a weapon:

https://www.wellsfargo.com@203.0.113.45/login

Your eye reads www.wellsfargo.com; your browser goes to 203.0.113.45. If a URL contains an @, the real destination is whatever sits to its right — always. Legitimate links essentially never carry embedded credentials either: beyond being a deception pattern, it drops the password into browser history and server logs.

4. Subdomain stacking

secure.account.verify.paypal.com.session-4471.xyz is the textbook version. It leans on two things: phones truncate long URLs from the right, showing you only the reassuring beginning, and a run of trustworthy words switches off careful reading. Any host with more than four labels deserves a right-to-left read before anything else. A close relative: subdomains or path segments that look like random noise (k7x2qm9v3p) are typically mass-generated campaign identifiers.

5. Shorteners

bit.ly, t.co, tinyurl.com and the rest aren't malicious — they're everywhere and often necessary. The problem is that they hide the destination by design, and that opacity is exactly what a phishing sender wants. A shortener in a message asking you to sign in is a combination that should never clear your filter. The honest limitation: expanding a short link requires asking its server, so no purely local analysis can do it for you.

6. Schemes that aren't http or https

A javascript: link doesn't go anywhere — it runs code in the page you're already on. A data: URL carries its entire payload inside the address bar, which lets someone serve a fake login page hosted nowhere at all. file: points at your own disk, and intent: launches apps on Android. None of these belong in a link that arrived by email or chat, and modern browsers block several of these cases for exactly that reason.

7. Contextual tells

Some clues prove nothing alone but stack up: a non-standard port (:8080, :4444) on something claiming to be a bank; a TLD with a well-documented abuse problem; a pile of tracking parameters that reveal which campaign you came from. Tracking is its own topic — see our piece on the UTM parameter mistakes that break your analytics — but a supposedly personal link stuffed with campaign tags tells you something about the sender.

Links that arrive inside a QR code

A QR code is a URL you cannot read. None of the rules above apply, because there is no text to inspect until the camera has already decoded it and your phone is offering a one-tap Open button. The fix is to split the two steps: decode first, decide second. The safe QR scanner pulls the payload out of an image or screenshot, shows you the URL in plain text, and runs the same checks it would run on a pasted link — without opening anything. If you want the attacker's-eye view, we've written about how malicious QR codes work.

What no signal can tell you

This is the part most articles on the subject skip, and it's the important one. Local heuristics detect suspicious structure, not intent. A short, clean HTTPS domain with no odd characters passes every check, and it might be a well-built phishing page, a legitimate site compromised this morning, or an expired domain somebody re-registered last week. The inverse happens too: an internal company link on an unusual port with an unreadable subdomain will light up several signals and be entirely harmless.

So the only thing a local inspection does well is exactly what it claims: break the URL apart, show you the real host, and explain what you're looking at. The decision stays yours, and your best evidence isn't in the URL at all — it's the context. Who sent it, were you expecting it, is the message manufacturing urgency, and does the company it claims to be from have any reason to reach you this way. When the answer is that you do need to sign in, sign in by typing the address yourself or from your own bookmark, never from the link.

You already clicked. Now what?

If you only opened the page and closed it, the risk is low: close the tab, don't go back, don't download anything. If you entered a password, change it immediately on the real site — typed in by hand — and anywhere else you reused it, then review the account's active sessions and connected apps. If the link came by email, it's worth finding out where it really originated: the email header analyzer lays out the Received chain, the Reply-To address and the SPF, DKIM and DMARC results, which is where sender spoofing shows up. And when you need to see what a domain actually publishes, the DNS checker resolves its records.

Frequently asked questions

Related tools

• Check if a link is safe — Breaks the URL apart and flags IP hosts, homographs and odd schemes.
• Scan a QR code safely — Decodes the code and inspects its link before you open it.
• Analyze email headers — Received chain, Reply-To and SPF, DKIM and DMARC results.
• Check DNS records — Resolve A, MX, TXT and CNAME records for any domain.

You might also like: what makes a QR code malicious.