IP Geolocation for Developer Applications

2026-03-24

IP geolocation maps an IP address to a physical location — country, region, city, and sometimes latitude/longitude. It's one of the most commonly used enrichment techniques in web applications, but it's also one of the most frequently misunderstood.

How IP Geolocation Works

IP addresses are assigned to organisations by regional internet registries (ARIN, RIPE, APNIC, etc.). Geolocation databases are built by:

Whois/RDAP lookups — registration data often includes a country and sometimes a city.
BGP routing data — the AS (Autonomous System) announcing a prefix reveals the operator's geography.
Active probing — latency measurements from known reference points triangulate physical location.
Commercial partnerships — ISPs license their own mapping data to database vendors.

The result is a database that maps IP prefixes (203.0.113.0/24) to locations. These databases are updated continuously but are never perfectly current.

Accuracy Expectations

IP geolocation accuracy degrades at finer granularity:

Granularity	Typical accuracy
Country	~99%
Region / State	~85%
City	~60–80%
Postal code	~50%
Street address	Not reliable

VPNs, proxies, and Tor completely defeat geolocation — the IP belongs to the exit node, not the user. CDNs and cloud providers (AWS, Google Cloud, Azure) have IPs registered to data centres, not end users.

Looking Up an IP with the DNS Toolkit API

curl -X GET "https://dns.toolkitapi.io/v1/ip/reverse?ip=8.8.8.8" \
  -H "X-API-Key: YOUR_KEY"

The response includes geolocation data alongside PTR records and ASN information:

{
  "ip": "8.8.8.8",
  "hostname": "dns.google",
  "asn": {
    "number": 15169,
    "name": "GOOGLE",
    "country": "US"
  },
  "geo": {
    "country": "United States",
    "country_code": "US",
    "region": "California",
    "city": "Mountain View",
    "latitude": 37.386,
    "longitude": -122.0838,
    "timezone": "America/Los_Angeles"
  }
}

Common Use Cases

Content Personalisation

Show users region-appropriate content — currency, language, shipping options — without requiring them to set a preference. Always let users override it: geolocation should be a default, not a cage.

Fraud Detection

A login from an IP geolocated to a country the account has never been accessed from is a signal worth investigating. Combine with device fingerprinting and behavioural signals, not as a standalone block.

Regulatory Compliance

Some content is restricted by jurisdiction (GDPR applies in the EU, certain financial products are country-specific). Geolocation provides a first-pass filter — pair it with proper legal terms and explicit user acknowledgement.

Rate Limiting by Region

Apply different rate limits or CAPTCHAs to traffic from regions associated with high abuse volumes. Be careful: this can also block legitimate users, including those using corporate VPNs that exit in a "flagged" region.

What to Avoid

Don't hard-block based solely on country IP. VPNs make this trivially bypassable, and it locks out legitimate users.
Don't display geolocation results as facts. "You are in London" is a guess. "We've personalised content for UK visitors" is more honest.
Cache the result. IP-to-geo lookups are slow network calls. Cache per IP with a TTL of at least an hour.

Integration Pattern

import httpx
from functools import lru_cache

@lru_cache(maxsize=1024)
def geolocate(ip: str) -> dict:
    resp = httpx.get(
        "https://dns.toolkitapi.io/v1/ip/reverse",
        params={"ip": ip},
        headers={"X-API-Key": "YOUR_KEY"},
        timeout=2.0,
    )
    if resp.status_code == 200:
        return resp.json().get("geo", {})
    return {}

# In your request handler:
country = geolocate(request.remote_addr).get("country_code", "unknown")

Summary

IP geolocation is a useful signal, not ground truth. Country-level accuracy is high; city-level accuracy is moderate. Use it for personalisation and soft signals in fraud detection, always with a fallback for incorrect results and user overrides.

Try it out

Browse Tools →