Phishing URL Checker

About Phishing URL Checker

Where a link actually goes, and which of the known tricks it uses to look like somewhere else. The first row of the result is the one that matters: the origin your browser will connect to, whatever the rest of the address appears to say.

This cannot tell you whether a link is a phishing attempt, and neither can anything else that only reads a URL. The most effective phishing of all arrives as an ordinary address on a legitimate site that has been broken into, and it passes every check here without a mark against it. So a clean result is never reported as "safe" — it means the address uses none of the structural tricks, which is a narrower statement and the only honest one available.

What it is good for is the other half. A large share of phishing links are trying to make a URL *look* like it points somewhere it does not, and those tricks are mechanical: a name before an @ that the browser discards, a brand sitting as a subdomain of something else, a Cyrillic letter standing in for a Latin one, a redirect parameter on a real site carrying somebody else's address. Each one is named and explained rather than scored, because knowing the trick is worth more than a verdict on one link.

The rule for a brand name works in both directions or it is useless: paypal.com is read as PayPal, and paypal.com.secure-verify.xyz is read as secure-verify.xyz — because a hostname means what its *end* says, and it is written so that the beginning is what gets read.

The other half needs a server, because a page cannot do it. Following the redirects to see where the link actually ends up, asking a registry how old the domain is, and looking at the certificate the destination presents are all requests somebody has to make — and they catch precisely the links the structural half passes. A shortener has a perfectly ordinary URL. So does a domain registered on Tuesday.

Domain age is the strongest single signal here. Phishing domains are bought for one campaign and abandoned; a name registered a week ago asking for a password is worth more than every structural check put together. It is also the one thing a browser has no way to find out.

The server also sorts what it finds into the three categories the reputation services use — social engineering, malware and unwanted software — but it arrives at them differently. A reputation service answers "has anyone reported this", which is a fact about the rest of the world and cannot be derived from the link. This answers "what does this destination actually serve", which can: a file named invoice.pdf.exe, a browser extension offered from somewhere that is not a store, a page titled "Sign in to your Microsoft account" served from a domain with no relationship to Microsoft. Every category carries the observations it rests on, so you can disagree with the conclusion instead of having to take it.

It also reads the link for a cross-site scripting payload, which is a different attack wearing the same clothes. There the address genuinely is the real site — that is the mechanism, not a disguise — and what it carries is script the site will echo back into its own page. Every check that asks "is this domain who it claims to be" answers yes, correctly, and the link is still hostile. The server then looks at whether the value actually comes back in the page: escaped, which is the site defending itself, or untouched, which is the hole standing open.

The destination's address is also put to the public DNS blocklists. That is a different trade from a URL reputation service and a better one: the lists are asked about an IP address, so the link — which in a real phishing message often carries your own email address or a one-time token — never leaves. What comes back is narrower than people assume, and is reported as such: these lists track mail abuse, so a hit means spam was seen leaving that address rather than that this page is hostile, and if the site sits behind a CDN the address belongs to millions of others and the answer means nothing about this one.

The two approaches fail in opposite directions, and that is the point of knowing which one you are holding. A site reported by everybody an hour ago is invisible here if it now serves an ordinary page. A campaign registered this morning that nobody has reported yet is caught here the moment it asks for a password. Neither is a substitute for the other.

That comes with a trade worth stating: the URL is sent to this application's server, and the server fetches it. A suspicious link often carries the recipient's own address or a one-time token, and that goes with it. The limits are specific — every redirect is re-checked before it is followed, only the final destination is read, the read stops at 128 KB, and nothing on the page is ever executed — but the link does leave your machine and something does arrive at it, which the structural half never did.

Where it helps

• Leads with the origin the browser will actually connect to, which is what every trick here is trying to obscure.
• Reads the registered domain properly, so a brand sitting as a subdomain of something else is caught and a real one is not accused.
• Catches lookalike characters and punycode, and shows what the name reads as to the eye.
• Finds another URL hiding in a redirect parameter, which is the one trick that survives a domain check.
• Follows the redirects and reports where you actually end up, which is the only thing a shortener is hiding.
• Reports how old the domain is — the strongest signal available, and one no browser can obtain.
• Checks the certificate at the destination rather than at the link, because a shortener's certificate says nothing about where you land.
• Explains each trick rather than scoring it, so the next link can be read without the tool.
• Re-checks every redirect hop against private addresses before following it, so the checker cannot be turned into a way of reaching things you could not.
• Names what the destination serves — a page, or a download, and under what filename — which is how a link that hands you a program is told from one that shows you something.
• Reads the destination's markup for the two things that decide a credential trap: whether it asks for a password, and whether the form sends it somewhere other than the site you are on.
• Sorts its findings into social engineering, malware and unwanted software from evidence it gathered itself, with the observations attached, rather than from a third party's list.
• Reads the link for cross-site scripting payloads — including percent-encoded and double-encoded ones — and names the parameter carrying them.
• Checks whether the site echoes the link's own values back into its page unescaped, which is what separates a link that carries a payload from one that works.
• Asks the public blocklists about the destination's address — which reveals the IP and never the link, so a personalised URL stays private — and says plainly when the address is shared and the answer cannot be attributed.

Limits

• It cannot tell you a link is safe, and does not try. A compromised legitimate site produces a completely ordinary URL.
• It reads structure only: it does not know who owns the domain, how old it is, what the page contains, or whether anybody has reported it.
• The brand list is short and covers the most-impersonated names. A link imitating something not on it gets no brand warning.
• The registered name uses a short list of multi-part suffixes rather than the full public suffix list, so an unusual one may be read a label out.
• Several signals — a cheap TLD, reassuring words, a long address — are common on entirely legitimate links and are reported as notes rather than faults for that reason.
• The URL is sent to this application's server for the live checks, so it is no longer examined only on your machine.
• Following the link means a request reaches it, which tells whoever runs it that somebody looked — from this server's address rather than yours, but it is not a silent check.
• Phishing kits routinely serve an innocent page to anything that is not a real browser in the right country. A destination that looks ordinary here may not be the page you would be shown.
• The page is read as markup, not run as a page. A sign-in form assembled by JavaScript is invisible to this, so the absence of a password field is not evidence there is no form.
• Only the first 128 KB of the destination is read, and the result says when it was cut short.
• The blocklists it asks are mail blocklists. They establish what a host has been seen sending, which overlaps with phishing without being the same thing, and they have nothing to say about a site whose address is clean.
• The link itself is checked against no reputation service, so a URL already known to the world for a week gets no credit for being known.

Frequently asked questions

It came back clean. Is the link safe?

No — it means the address does not use any of the structural tricks. That is genuinely useful and it is not the same question. A real site that has been broken into serves phishing from a perfectly ordinary URL, which is why that kind is the most effective. If you were not expecting the message, the address being well-formed changes nothing.

How do I read a hostname myself?

From the right. The registered name is the last two labels — the bit immediately before the final dot and the one after it — and everything to the left of that was chosen by whoever owns it. paypal.com.secure-verify.xyz is a domain called secure-verify.xyz with paypal and com written as subdomains, and it is built that way because addresses are read left to right.

Why does a link on a real domain get flagged?

Most likely a redirect parameter. Many real sites accept a URL in the query string and send you there after signing in, and if they do not check it, anybody can attach their own address to the site's good name. The link really is on the real domain; it simply does not leave you there.

Does using this tell the phisher somebody looked?

It makes a request to the link, so yes — but from this application's server rather than from you, and without your address, your browser or any cookie. Following the chain uses HEAD requests, which ask for headers and no content. The final destination is then fetched properly, because whether a page asks for a password can only be answered by looking at it — capped at the first 128 KB, with the connection dropped afterwards. What never happens is execution: no script runs, no image or stylesheet is fetched, and the markup is scanned as text. If even that is more contact than you want, read the structural findings and ignore the rest.

What do social engineering, malware and unwanted software mean here?

They are the three categories the reputation services sort links into, and they map to the question worth asking: is this after my password, is it trying to run code on my machine, or is it trying to install something I did not ask for. Social engineering means the destination presents itself as somebody it is not, or collects a password and sends it elsewhere. Malware means it hands your machine something built to run — an executable, or a document name hiding one. Unwanted software means something that installs itself into your browser or phone from outside a store that reviews what it distributes. Each verdict lists what it was based on, and says whether the evidence makes it *likely* or merely *possible*.

Nothing was flagged in any of the three categories. Does that settle it?

No, and there are two specific reasons why not. Phishing kits commonly serve an innocent page to anything that is not a real browser in the right country, so what this fetched may not be what you would be shown. And the page is read as markup rather than run, so a sign-in form built by JavaScript leaves no trace here. An empty result means none of the three could be substantiated from what was fetched — which is a narrower statement than the destination being fine.

Does it check the link against a blocklist?

Not the link — the address. The destination's IP is asked about on the public DNS blocklists, and that distinction is the whole point: a suspicious link is very often personalised, carrying your email address or a one-time token so the sender knows who clicked, and handing that to somebody else's reputation service would leak exactly the thing you are being careful about. An IP address carries none of it. What is *not* done is submitting the URL itself to a third-party reputation API, which is a separate decision and one to make deliberately. So the three harm categories are worked out from what the destination actually serves — which catches a campaign nobody has reported yet, and misses a known-bad site that has gone quiet. Worth knowing in both directions.

The link has a <script> tag in it. Is that dangerous?

It depends on what the site does with it, and that is the second half of the check. A payload in the link is only an attempt; it becomes an attack when the site writes the value back into its own page without escaping it. So the value is looked for in the response: if it comes back with its angle brackets turned into &lt; and &gt;, the site is defending itself correctly and the link is inert. If it comes back untouched, the script runs as that site, with whatever you are signed in as — and that is worth reporting to whoever runs it. Note that anything after a # never reaches the server at all, so the site cannot defend against it and only its own JavaScript can.

The address is on a blocklist. Does that settle it?

No, and it is worth knowing what those lists actually measure. They are built for mail: a listing means spam was seen leaving that address, which is a fact about the machine and only sometimes a fact about a website hosted on it. A compromised server sending spam and a phishing page are often the same box, which is why it is reported at all — but it is corroboration, not a verdict. The reverse matters more: if the destination sits behind a CDN, its address fronts millions of unrelated sites, so neither a listing nor its absence can be attributed to this one. The result says when that is the case rather than letting you draw the conclusion.

The domain is only a few days old. Is that conclusive?

It is the strongest signal on the page and it is not proof — every legitimate site is new once. What makes it damning is the combination: a name registered last week, presenting itself as an established bank, asking for a password. A week-old domain for a week-old project is simply a week-old project.

Related tools

• IDN Homograph Detector — Check whether a domain name is imitating another one
• URL Encoder — Percent-encode components or whole URLs
• Email Header Analyzer — The delivery path, the authentication results, and what a forgery looks like
• DNS Lookup — Resolve A, AAAA, MX, TXT, NS, CNAME, SOA and CAA records
• Log Analyzer — Summarise a log: rates, errors, slowest paths and busiest clients
• HAR Analyzer — A network recording as a waterfall: what was slow, heavy, uncached or failing

More Analyzers tools

• Log Analyzer — Summarise a log: rates, errors, slowest paths and busiest clients
• HAR Analyzer — A network recording as a waterfall: what was slow, heavy, uncached or failing
• IDN Homograph Detector — Check whether a domain name is imitating another one
• Injection Filter Tester — Standard probes per context, and whether your escaping survived them
• Stack Trace Analyzer — Read a stack trace or crash in any common language: the cause, your frames, and what it usually means