IP lookup
An IP lookup answers three questions: where an address is, who runs the network behind it, and what kind of connection it is. IPOK answers all three in one free check with no signup, and then goes one step further: it shows the evidence that up to 9 active risk sources hold about the address, source by source, so you can see why an IP looks clean or suspicious instead of trusting a single number.
On 2026-10-18 we looked up four well-known public addresses from a single test server (Fastly network, AS54113, located in Seattle) and compared IPOK’s answers with neutral references: RIPEstat for routing and registry data, the Tor Project’s official exit list, and AWS’s published ip-ranges.json. In all four cases the ASN, the country and the connection type IPOK reported matched the references.
| IP | What IPOK returned | Reference | Verdict |
|---|---|---|---|
| 1.1.1.1 Cloudflare DNS (anycast) | AU / South Brisbane · AS13335 · hosting · risk 18 · 9 sources answered | AS13335, APNIC; ipinfo: Brisbane AU, anycast | Country, ASN and type match. City is one of many anycast locations. |
| 8.8.8.8 Google DNS (anycast) | US / Ashburn · AS15169 · hosting · risk 11 · 9 sources answered | AS15169, ARIN; ipinfo: Mountain View, anycast | ASN and type match. City differs between databases, which is normal for anycast. |
| 171.25.193.25 Tor exit | SE / Stockholm · AS198093 DFRI · hosting · risk 90 · signals tor / blocklisted / abuser / hosting | Listed in the official Tor bulk exit list; RIPEstat AS198093; ipinfo: Stockholm | Tor correctly identified; country, city and ASN match. |
| 54.156.0.101 AWS EC2 us-east-1 | US / Ashburn · AS14618 · hosting · risk 65 | AWS ip-ranges.json: EC2 us-east-1, 54.156.0.0/14; RIPEstat AS14618 | ASN, region and type match the AWS-published range. |
Tested 2026-10-18 16:25 Beijing time (UTC+8), one test location. Most risk-source answers were served from cache (read between Oct 16 and Oct 18). Four addresses is an illustration, not a statistically meaningful benchmark. An earlier run the same day (13:26) typed 1.1.1.1, the Tor exit and the AWS address as “business”; a type-mapping fix went live at 15:56 and this table is the re-test after it.
What the check shows plainly: the network owner and country are the dependable part of any IP lookup, and IPOK got them right in every case. City is the weak part, especially for anycast resolvers that are announced from dozens of locations: 8.8.8.8 is placed in Ashburn by IPOK and in Mountain View by ipinfo, and neither is wrong. Connection type is where databases most often disagree, which is why the result page lists each source’s own type verdict.
Hosting classification checks the operator-published ranges below. The build supports IPv4 and IPv6 from AWS, GCP, Cloudflare, DigitalOcean, and Linode; actual coverage depends on each source and the retained snapshot. Both families are not guaranteed for every source or build. Oracle and AzureCloud are IPv4-only in this implementation.
Failed refreshes retain older snapshots and their original fetch times; a rebuild does not mean every source was updated. Freshness follows the actual fetch time and upstream expiry. Missing coverage or expired data does not mean clean. See per-source coverage and dates in the methodology.
The Azure link is Microsoft's Service Tags download confirmation page. The build follows its ServiceTags_Public JSON link and uses only the IPv4 prefixes in the AzureCloud tag. A hit means the address falls in a range that vendor published. It is not a fraud verdict, and it does not by itself raise the score into the high-risk band.
Public resolvers such as 1.1.1.1 and 8.8.8.8 are anycast: the same address is announced from many data centres and your packets go to the nearest one. A geolocation database has to pick one city, so different lookup sites disagree and none of them is wrong in a useful sense. For anycast, read the ASN (AS13335, AS15169) and the registry, not the city.
For lists and ranges, use batch lookup or the API. /api/batch gives a quick estimate for many IPs or an IPv4 CIDR from ip-api plus IPOK’s offline lists, and /api/cidr summarises the VPN, Tor and abuse share of a range (each range up to a /16, at most 65,536 addresses per request) without extra upstream calls. Both are faster and lighter than the single-IP check, so use the single-IP check when one address matters.
curl -sL https://ipok.io/check?ip=1.1.1.1 prints a coloured report in the terminal, and https://ipok.io/api/ip?ip=1.1.1.1 returns the full JSON: geo, ASN, type, risk with its breakdown, each source’s answer with the time it was observed, and a quota block that tells you how many lookups remain today. The API is free, keyless and CORS-enabled, with fair-use limits of 20 self-lookups and 15 specified-IP lookups per UTC day per source IP. See the developer docs. If you’d rather call a vendor directly, the free tiers of ten IP data APIs are compared side by side. If you publish data from IPOK, credit IPOK with a link to ipok.io.
An IP lookup describes the address, not the person or the account using it. It cannot see your device, your browser fingerprint, your payment details or a platform’s internal rules, so no score or label here is a promise that a sign-up, login or payment will go through. If you need to know whether your own connection leaks a different address, use the separate IP leak test.
Open https://ipok.io/en and type any public IPv4 or IPv6 address, or leave it empty to check your own connection. There is no signup. From a terminal, curl -sL https://ipok.io/check?ip=1.1.1.1 prints the same report, and GET https://ipok.io/api/ip?ip=1.1.1.1 returns JSON without an API key.
Country and network owner (ASN) are usually reliable; city is a probability, not a fact. In IPOK's 2026-10-18 spot check of four public IPs, the ASN, country and connection type matched the reference sources every time, while the city of anycast addresses differed between databases. Small sample, one test location: treat it as an illustration, not a benchmark.
Each site licenses or builds a different geolocation database, and anycast addresses such as 1.1.1.1 or 8.8.8.8 are announced from many locations at once, so there is no single correct city. The registration country (from the regional internet registry) and the ASN are the more stable fields to compare.
Yes. https://ipok.io/en/batch and /api/batch give a quick estimate for a list of IPs or an IPv4 CIDR using ip-api plus IPOK's offline lists, and /api/cidr summarises VPN, Tor and abuse share for a range of up to a /16 (65,536 addresses per request). Batch results are a fast estimate and are not the same as the full multi-source check for a single IP.
Yes. The IPOK API is free, needs no key and allows cross-origin requests. Fair-use quotas are counted per source IP (IPv6 per /64): 20 self-lookups and 15 lookups of a specified IP per UTC day for /api/ip. If you publish IPOK data, credit IPOK with a link to https://ipok.io.
IPOK has no accounts and does not store a per-request history of who looked up which IP. It keeps rate-limit counters per source IP and a shared cache of risk-source answers per target IP (normally 72 hours), and these are not linked to each other. Details and retention periods are on the privacy page.
An Autonomous System Number identifies the network that announces the IP on the internet, for example AS15169 for Google or AS14618 for an AWS region. The ASN tells you who operates the address and is usually the quickest way to tell a home broadband line from a cloud server.
Last checked 2026-10-18. Accuracy figures come from a test IPOK ran itself on 2026-10-18; how the score is built: methodology.