Is This Link Safe?
Design principle: a stored Safe result is never enough by itself. Before the service returns Safe, the current authoritative threat-list check must complete. If that required provider is unavailable or returns an invalid response, the result is Unknown rather than Safe.
What the checker analyzes
The checker accepts a public HTTP or HTTPS URL. It analyzes the submitted address, the normalized hostname, prior domain evidence, lookalike patterns, the website's resolved public IP when available, and current Web Risk threat-list matches. The service does not load the destination page inside your browser.
This is URL and infrastructure risk analysis. It is not a browser sandbox, file antivirus, business-verification service, or promise that a person sending a message is genuine.
The checking pipeline
| Stage | What happens | Possible effect |
|---|---|---|
| 1. URL validation | Accept public HTTP(S), reject credentials/private targets, remove the fragment. | Invalid URLs are not scanned. |
| 2. Domain evidence | Read the latest stored verdict for the normalized domain. | Stored Dangerous or Suspicious evidence can warn immediately; Safe is context only. |
| 3. Lookalike check | Run local URL features and expose confirmed typosquatting signals. | A lookalike-domain signal returns Suspicious. |
| 4. IP reputation | Resolve the site's public IP and query cached or current AbuseIPDB reputation. | Elevated abuse reputation can return Suspicious or Dangerous. |
| 5. Web threat list | Send the URL to Google Web Risk Lookup for configured threat types. | A match returns Dangerous; a completed clean lookup permits the final decision. |
| 6. Final decision | Combine completed signals and save the domain verdict for future evidence. | Return Safe only after the required current check succeeds. |
1. URL validation and normalization
The service accepts only http:// and https:// addresses up to 2,048
characters. URLs containing an embedded username or password are rejected. Localhost, private
IPs, and other non-public targets are rejected to prevent the public checker from being used to
reach internal services.
The client-side fragment after # is removed because it is not sent in an HTTP
request and may contain sensitive application state. The hostname is normalized for the domain
checks. Plain HTTP is retained for scanning but becomes a Suspicious transport-security signal.
2–5. Security signals
Known domain verdicts
The local database stores one latest verdict per normalized domain. Existing Suspicious or Dangerous evidence can stop the scan early and warn the user. A stored Safe value never stops a current scan because a previously clean domain can be compromised later.
Typosquatting detection
The local analysis service inspects URL features and can identify a domain that resembles a popular site. Only the explicit typosquatting outcome affects the public verdict; other model outputs currently remain in shadow mode and do not silently classify a user-facing result.
AbuseIPDB infrastructure reputation
When DNS resolution succeeds, the site's public IP can be checked against AbuseIPDB. A configured confidence threshold of 40 or more produces a warning; 80 or more produces a Dangerous result. This is evidence about reported activity from an IP, not proof that every domain hosted on that address is malicious. Shared hosting can therefore create false-positive risk.
Google Web Risk URL lookup
The full submitted URL without its fragment is sent to the Google Web Risk Lookup API for the configured threat types. A returned match produces a Dangerous verdict and includes the threat type in the explanation. An empty completed lookup means no configured Web Risk list matched; it does not mean Google guarantees the URL is harmless.
How signals become a verdict
Safe · Low risk
HTTPS or otherwise no elevated local/IP signal, plus a successfully completed current Web Risk lookup with no threat match.
Suspicious · Medium risk
Examples include unencrypted HTTP, a typosquatting signal, a stored Suspicious verdict, or elevated infrastructure abuse reputation.
Dangerous · High risk
A stored Dangerous record, high infrastructure-abuse confidence, or a current Google Web Risk threat match.
Unknown · No verdict
The authoritative Web Risk check was unavailable, malformed, or incomplete. The service fails closed instead of presenting an outage as Safe.
What information is processed
- The URL without its browser-only fragment is sent to the islinksafe.com backend.
- Google Web Risk Lookup receives the checked URL.
- AbuseIPDB may receive the destination website's resolved public IP—not the user's IP.
- The normalized domain, verdict, source, and details may be stored as threat evidence.
- Operational request information is used for rate limiting, reliability, and abuse prevention.
URLs can contain sensitive values in their path or query string. Do not place passwords, access tokens, private document links, or recovery codes in a URL you submit. The current handling and retention disclosures are documented in the privacy policy.
What the service does not check
- It does not render or visually compare the destination page.
- It does not download or execute files and is not a malware sandbox.
- It does not guarantee expansion and analysis of every redirect target.
- It does not prove that an offer, seller, support agent, or message sender is legitimate.
- It cannot guarantee detection of a new threat that is absent from reputation data.
- It cannot guarantee that a clean page will remain unchanged after the scan.
Use the verdict as evidence, not permission. For passwords, payments, crypto assets, identity documents, and recovery codes, independently verify the destination and the request even after a Safe result.
Reliability and incorrect results
Optional reputation services can degrade without converting the final answer into Safe. The current authoritative URL threat check is required for a Safe verdict. Result cards on the main checker explain the primary signal and let users report a suspected false positive or false negative for investigation.
Provider lists and abuse reports can contain errors. Google explicitly states that Web Risk data may miss risky sites or classify a safe site incorrectly. See the official Web Risk overview and AbuseIPDB Check endpoint documentation.
Continue investigating
Review a suspicious URL
Run the free checker, read the reasons behind the result, and independently verify sensitive requests.
Check a link now