Detection Accuracy and Testing
How we validate 2check.click against real phishing threats, what we detect reliably, and where current limitations lie.
- Privacy Focused
- No Login Required
- No Personal Data Collected
- Anonymous Analysis
- Educational Security Platform
Testing Overview
Every change to the detection engine is validated against a structured test corpus before it reaches production. The corpus is split into three parts, each targeting a different aspect of 2check.click's analysis pipeline.
URL Testing
We test against samples drawn from three public threat intelligence feeds — URLhaus, OpenPhish, and the GitHub Phishing.Database — covering over 300 confirmed malicious URLs. Alongside these, a hand-curated set of 98 benign URLs (popular legitimate sites, official brand domains, government portals) serves as the false-positive control. Both sets are re-tested on every code change.
Message Testing
The message analyzer is validated against 100 hand-labeled samples — 50 confirmed phishing messages (SMS, email, and chat formats) and 50 benign messages (routine notifications, order confirmations, delivery alerts). Each case is reviewed individually to ensure the label reflects the genuine intent of the message, not just superficial phrasing.
Threat Intelligence Validation
Beyond pass/fail accuracy, we track detection rate by threat category — brand impersonation, delivery scams, government lures, credential harvesting — to identify systematic gaps. When a category falls below threshold, it triggers a targeted rule improvement cycle rather than generic score inflation, which would hurt the false-positive rate.
Current Results
Results from our most recent validation run. These figures are updated with each detection engine release.
Detection rates are measured at MEDIUM risk level or above (risk score ≥ 26). False positive rate is measured on a curated benign corpus of 98 URLs — none flagged at any risk level.
What We Detect Well
The detection engine is specifically designed for URL-level signals — things that are visible in the link itself without visiting the destination page.
Phishing domains and lookalike URLs
Domains that visually resemble well-known brands using homoglyph characters, digit substitution, or keyboard-adjacent typos — for example paypa1.com or arnazon.com.
Brand impersonation attacks
Brand names embedded in subdomains or paths to create the appearance of legitimacy — such as amazon.com.fake-site.net or login.microsoft.com.phishing.xyz.
QR code scams
QR codes pointing to phishing URLs benefit from the same URL analysis as typed links, since the QR is decoded locally before the destination is assessed.
Delivery scams and government lures
Message-level analysis detects urgency patterns, fake parcel-tracking requests, and tax/benefit keyword combinations commonly used in SMS and email phishing.
URL obfuscation techniques
Percent-encoding, double-encoding, base64-embedded URLs, HTML entities, and Unicode escapes are all decoded and the underlying destination is analyzed.
Suspicious redirect chains
Short link resolution uncovers multi-hop redirect chains, and each intermediate hop is scored for risk independently — not just the final destination.
Known Limitations
Honest detection means acknowledging what 2check.click cannot reliably catch. These are structural constraints of client-side, URL-only analysis — not oversights.
Content-only phishing
Phishing sites that use a clean, unrelated domain with no brand references in the URL are invisible to URL analysis. The deception lives entirely in the page content — which 2check.click never downloads or renders, by design.
Newly registered clean domains
A brand-new domain with a neutral name and no suspicious keywords looks identical to a legitimate new business. Without page content or behavioral signals, there are no URL-level indicators to score.
Social engineering without URL indicators
Phishing that relies on relationship context — such as a message that appears to come from a known contact and links to a credible-looking shared document — may carry no signals detectable from the link alone.
Zero-day brand impersonation
A domain impersonating a brand not yet in our database will not trigger brand-specific detection. The brand database currently covers around 200 well-known names and is expanded in maintenance cycles.
Why Transparency Matters
Security tools that publish their own limitations are rare — and for good reason. An attacker who knows exactly where a tool fails can engineer around it. But for a consumer-facing phishing checker aimed at non-technical users, the calculus is different.
The people who rely on 2check.click are not security researchers probing for gaps — they are someone who just received a suspicious text message and wants to know if it is safe to click. For them, informed trustis the goal. Knowing that the tool catches 96% of known threats, while being transparent that freshly registered clean-looking domains can slip through, helps users make better decisions than a vague claim of "comprehensive protection" ever could.
Transparency also drives continuous improvement. Every false positive or missed threat reported through Report a Problem feeds directly into the next rule update. Users who understand what the tool is trying to do — and where it struggles — submit far more useful feedback than users who just know it sometimes gets things wrong.
Finally, publishing a structured test methodology creates accountability. Numbers on this page are derived from a reproducible corpus, not from selecting favorable examples. If the detection rate drops, we will update these figures honestly — and fix the underlying rules.
Frequently Asked Questions
How accurate is 2check.click?
Across our validation suites, 2check.click currently achieves approximately 96% detection on URLhaus threat feeds, 94% on phishing messages, and 0% false positives on clean benign URLs. These numbers reflect our automated test corpus, which we run against every code change to catch regressions before they reach production.
Can phishing evade detection?
Yes. Some phishing campaigns are specifically engineered to evade URL-level analysis. Attackers can register clean-looking domains with no brand references in the URL, use freshly registered domains with no suspicious history, or rely entirely on deceptive page content that only a browser rendering the page can see. These are known structural limitations we document openly on this page rather than quietly ignore.
Why are false positives important?
A false positive — flagging a legitimate site as suspicious — erodes trust just as much as a missed threat. If a tool cries wolf too often, people stop trusting its warnings and start ignoring all alerts. Keeping the false positive rate at zero is therefore a hard constraint we test continuously, not an aspirational target. If you see a legitimate site flagged, please report it — those reports go directly into rule tuning.
How often are detection rules updated?
Detection rules are updated with each release. The engine is currently in maintenance mode — new heuristics are only added to fix confirmed false negatives or false positives, not to expand scope arbitrarily. Every change is validated against the full test corpus before shipping to ensure no regressions are introduced.
What data sources do you use for testing?
Our validation suite draws from three public threat intelligence feeds — URLhaus, OpenPhish, and the GitHub Phishing.Database — plus a hand-curated set of 98 benign URLs and 50 benign messages. All test samples are run locally; no URLs or messages are sent to external services during testing.
Found a false positive, or spotted a scam we missed? Report a problem — every report shapes the next detection update.
Ready to try it? Analyze a suspicious link →