We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Check the security risk profile of an IP address, including key threat intelligence like threat types, reputation scores, and geolocation.
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
Submit one IPv4 or IPv6 address to request a returned profile. Depending on the response, the page can show country, region, city, district, continent, country code, ISP, owner, usage scenario, latitude and longitude, location radius, risk level, score, tags, and a capture time. Missing fields appear blank. You can choose WGS84 or BD09 for the coordinate-system option and copy the returned profile.
Risk tags are labels returned with the lookup, not a universal verdict. The page's own tag notes associate Proxy with proxy use, Sec_Dial / IDC with dial-up or data-center signals, VPN / Tor with those network types, and Scan / Brute_Force with scanning or brute-force activity. The provider, data coverage, score scale, scoring method, and refresh schedule are not disclosed here, so a number or tag cannot establish that an address is safe or malicious.
IP reputation is one clue for investigation. Compare it with the address's network context, logs, and other independent evidence before deciding what it means.
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Paste an IPv4 or IPv6 address, not a website name or URL. Check for missing characters or extra punctuation.
Select WGS84 or BD09 if you plan to interpret the returned latitude and longitude. Keep that selection with any coordinates you copy.
Separate location and network attribution fields from risk tags, level, score, and capture time. A blank field means no value was returned for that field in this response.
Copy the result if needed, then check important findings against your own logs and a trusted source appropriate to the investigation.
For example, a proxy-related tag may be a reason to inspect a connection more closely; it is not proof of abuse. A location label is an estimate and should not be treated as a person's precise physical location.
Use cases
See how the tool fits into real work and everyday tasks.
An analyst reviewing an unfamiliar address can use returned ownership and tags as a starting point, then compare them with authentication and network logs.
A team can copy the profile and capture time into its case notes while recording that the score method and source coverage are undisclosed.
Q&A
Find concise answers to common questions and confusing cases.
No. The score scale and method are not disclosed, and a profile is only one source of information. It cannot prove the absence of abuse.
The response may not contain every profile field. Blank location, owner, or risk fields should be treated as unavailable, not as a confirmed negative result.
No. The result may include a location radius, and IP-based location is an attribution clue rather than a verified person's physical location.
Do not treat a tag or score alone as a definitive block rule. Corroborate it with your own context and apply your organization's review process.
Notes
Review scope, result limitations, and important precautions before use.
Provider identity, underlying datasets, geographic coverage, score interpretation, and update timing are not disclosed in the result interface. Do not use this page alone to attribute an attack, identify a person, or make a high-impact access decision. Location fields can be approximate, and network assignments can change.
Related
Discover related tools, collections, and available API capabilities.