Is This Link Safe?
The most important finding is methodological: these datasets measure different things. Request logs count successful checks, while the domain table stores one latest verdict per domain and includes imported records. They cannot be joined into a valid “percentage of scans that were dangerous” with the currently stored fields.
Dataset and scope
The figures below come from read-only production database queries. The request window contains
successful /api/analyze requests recorded from March 27 through August 19, 2026.
The domain-verdict distribution is a separate database snapshot taken on August 22, 2026.
No raw IP addresses, submitted URLs, domains, query strings, or individual feedback records are published in this report. Counts are aggregated. This is an operational snapshot, not a peer-reviewed study or a representative sample of the public web.
Successful analysis requests
| Window | Successful analysis requests | Distinct stored IPs |
|---|---|---|
| March 27–August 19 | 3,606,728 | 23,477 |
| Last 90 days | 2,347,329 | 16,132 |
| Last 30 days | 801,689 | 5,431 |
| Last 7 days | 190,183 | 1,532 |
| August 19 only | 27,391 | 355 |
“Distinct stored IPs” must not be read as people or installed extensions. One person can use multiple network addresses, many people can share one address, and VPNs, mobile networks, NAT, IPv6 privacy rotation, websites, extensions, and automated clients can all change the relationship.
Request activity is highly concentrated
Across the full period, the top 1,000 stored IPs produced 2,159,598 successful checks—59.9% of all recorded analysis requests. A smaller group of 491 IPs with more than 1,000 checks each produced 48.2% of the total.
In the last 30 days, 94.51% of recorded requests occurred after the first five checks for the same IP-day. That is consistent with extension-like repeat checking, automation, or clients claiming an extension source, but the deployed request table did not store a reliable client source. The data therefore cannot prove which explanation applies to each request.
Current domain-verdict snapshot
| Latest stored verdict | Domain records | Share of table |
|---|---|---|
| Safe | 1,043,640 | 99.9469% |
| Suspicious | 533 | 0.0510% |
| Dangerous | 21 | 0.0020% |
| Total | 1,044,194 | 100% |
This does not mean 99.95% of user-submitted URLs were safe. The domain table contains one current row per normalized domain, mixes imported and organically checked records, and does not retain a complete verdict event for every request. A clean domain row can also become stale as websites change.
Why the clean-domain corpus needs careful handling
The current table is dominated by Safe records. Persisting routine clean lookups indefinitely adds storage but provides limited future decision value. The checking pipeline now treats a stored Safe record only as context and requires a fresh authoritative threat-list check before returning Safe. Suspicious and Dangerous evidence can be retained longer, but it also needs a source timestamp and revalidation policy.
What the data supports
Substantial repeat usage
Millions of accepted requests and concentrated high-frequency activity show that many checks are repeated, not one-off landing-page submissions.
A large domain cache
The service has accumulated more than one million unique normalized domain rows, almost all currently labeled Safe.
Threat evidence is rare in the table
Only 554 current rows carry a Suspicious or Dangerous verdict, but the schema cannot turn that snapshot into a per-scan detection rate.
Measurement needs source fields
Reliable attribution requires stored client source, extension version, final verdict, degraded state, and explicit accepted/rejected counters.
Limitations of this report
- The request log stores successful accepted analyses and omits some rejected or rate-limited traffic.
- It does not store the final link verdict for every request.
- It does not reliably distinguish website, extension, automation, or forged client labels.
- Stored IP counts are network identifiers, not identity-level users.
- The domain table is latest-state data rather than an immutable history of verdict events.
- Imported domain data and user-triggered checks are mixed in the same table.
- The sample is self-selected by product usage and cannot represent the whole internet.
What the next report should measure
A stronger follow-up report should be generated from daily aggregates that do not publish raw user identifiers or URLs. The event schema should record a pseudonymous client key, an explicit source category, extension version where applicable, final verdict, provider completion state, latency, and whether a request was accepted or rate limited.
With those fields, a future report could responsibly compare website and extension usage, measure the share of Unknown/degraded checks, track verdict changes over time, and publish threat categories without claiming that a network address equals a person.
Product methodology
For an explanation of URL validation, stored domain evidence, typosquatting, AbuseIPDB, Google Web Risk, fail-closed behavior, and privacy trade-offs, read How Link Checking Works. To investigate a specific URL, use the phishing link checker.
Related resources
Check a suspicious link
Use the free checker for a current verdict, then interpret it with the limitations documented in this report.
Open the free checker