IP / ASN / GeoIP Lookup

Enter an IPv4 or IPv6 address. We query RDAP for the network range, country, organisation, and abuse contact, and resolve the PTR record at the same time.

Try an example: 1.1.1.1 · 8.8.8.8 · 2606:4700:4700::1111

How this IP, ASN and GeoIP lookup works

Every routable IP address is allocated by one of the five regional internet registries (ARIN, RIPE, APNIC, LACNIC, AFRINIC) to a network operator. The operator publishes it under an ASN (Autonomous System Number). The allocation record covers the range, the registered organisation, the country, and the abuse contact. It's queryable over RDAP, the JSON protocol that replaced legacy WHOIS.

Type an IP into the form and the tool fetches its RDAP record, resolves the PTR in the same pass, and shows you the parent CIDR, the organisation, the ASN, the country, and the abuse address you'd email about spam or scanning. IPv4 and IPv6 are both supported.

What does the abuse contact actually do?

It's the address a network operator publishes for complaints about traffic from their range. Spam, scanning, scraping, brute-force attempts on SSH. Every public IP block is required to have one. Sending evidence (full headers, timestamps in UTC, sample log lines) gets faster results than a one-line "please stop."

What to do: if the abuse desk goes silent for a week, escalate to the responsible RIR. Sustained non-response can get a network's allocation reviewed.

Why does the country sometimes look wrong?

RDAP reports the country the block is registered in, not where the server actually sits. A South African hosting tenant on a Hetzner range will read as DE. A Cloudflare edge IP serving Cape Town traffic will read as US. The registry data is honest about the allocation, but it isn't a geolocation feed.

What about private and reserved ranges?

Anything inside an RFC 1918 block, link-local space, or a documentation prefix gets flagged before the RDAP query runs. There is no public registration for these: 

10.0.0.0/8        ← RFC 1918 private
172.16.0.0/12     ← RFC 1918 private
192.168.0.0/16    ← RFC 1918 private
192.0.2.0/24      ← RFC 5737 documentation
169.254.0.0/16    ← link-local

If you see one of these in a log and you weren't expecting it, the source is on your own network or someone forged the header.

Where to go next

Trying to work out whether an IP is the source of inbound spam? Run it through the blacklist checker to see which RBLs and DBLs have it listed. To confirm the address's PTR round-trips cleanly (the FCrDNS check most mail servers run before accepting mail), the reverse DNS checker tests both directions in one pass. For the registration side of a domain rather than an address, the WHOIS lookup is the matching tool.

Frequently Asked Questions

Common questions about RDAP, ASNs, and IP intelligence.

An Autonomous System Number identifies the network that announces a block on the public internet. Usually that's an ISP, a hoster, or a large enterprise. The IP on its own tells you nothing about who's responsible for the traffic. The ASN does.

It's also the fastest way to spot a category mismatch. If a connection claiming to be your bank arrives from an ASN owned by a residential ISP in a country you don't operate in, that's worth a closer look. If a "transactional" sender is on an ASN known for snowshoe spam, the deliverability problem isn't your DKIM.

RDAP only publishes the country the block is registered in. City and region data needs a commercial inference database (MaxMind, IP2Location, DB-IP), which is built from BGP scraping, latency probes, and Wi-Fi triangulation rather than registry records.

We don't ship one here. The licensing is restrictive, the accuracy on IPv6 and cloud ranges is poor, and a "Johannesburg" pin on a Cloudflare anycast IP isn't useful information. If you genuinely need city-level data for fraud scoring, buy a feed from one of those vendors directly.

Three usual causes. The redirector at rdap.org couldn't route the query (rare). The responsible RIR's RDAP server returned an error or timed out. The address falls inside a special-use range (RFC 1918 private space, documentation, link-local) with no public registration.

If a normal-looking address keeps failing, retry in a minute. RIR servers throttle, and APNIC and LACNIC have brief outages a few times a year. Sustained failures usually mean the query was rate-limited, not that the block doesn't exist.