IP Address Coverage

Dataset scope

The IP geolocation database covers the vast majority of publicly routed address space. Coverage is tracked at the prefix level — each allocated or announced IP block is mapped to a geographic location and network attribution record. Unrouted, reserved, and IANA-special-purpose ranges (such as RFC 1918 private ranges and loopback addresses) are outside the dataset by definition, as they carry no meaningful geolocation signal.

Geolocation fields

For each IP address the API returns a geolocation record with the following fields. Geographic accuracy degrades at finer granularities — country-level is highly reliable, while city-level placement reflects the typical registration or routing hub for the block and may not correspond to the physical location of an individual user.

Network and ASN fields

ASN (Autonomous System Number) and network attribution are derived from BGP routing data. These fields are available for all publicly announced prefixes and are useful for identifying carrier, hosting provider, or corporate network context. ASN data is generally more reliable than city-level geolocation for distinguishing network operator type.

Connection type classification

Each IP address is classified into a connection type based on routing signals, ASN characteristics, and allocation pattern. This is useful for distinguishing residential users from corporate networks, data centres, and mobile carriers — for example, to apply different rate limits, fraud scoring, or personalisation logic.

VPN and proxy detection

The is_vpn, is_proxy, and is_tor fields flag IP addresses that are known to operate as anonymisation services. Detection is based on a combination of known VPN provider range lists, Tor exit node registries, open proxy databases, and hosting-range analysis.

These fields are useful for fraud prevention, bot detection, account security, and access control workflows. Note that VPN detection is probabilistic — a new or private VPN exit may not yet appear in the database, and high-confidence flags require a current list update cycle.

Database update pipeline

IP geolocation accuracy depends on how frequently allocation, routing, and registry data is refreshed. The Map Zena IP dataset is maintained through automated pipelines that pull from BGP routing data, RIR (Regional Internet Registry) allocation feeds from ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC, and additional commercial enrichment sources. This keeps coverage current as IP blocks are reallocated, renumbered, or transferred between operators.

VPN, proxy, and Tor lists are updated on a shorter cycle than the core geolocation data, given the higher churn rate of anonymisation infrastructure.

IPv6 coverage detail

IPv6 coverage tracks BGP-announced prefixes from /32 (regional ISP allocation) down to /128 (individual host). The database resolves queries at the most specific announced block level available. IPv6 geolocation accuracy is broadly comparable to IPv4 for regions with mature IPv6 adoption; some regions have less granular IPv6 registration records, which can reduce city-level precision.

Both full-form (2001:0db8:85a3:0000:0000:8a2e:0370:7334) and compressed IPv6 notation (2001:db8:85a3::8a2e:370:7334) are accepted as query input and normalised before lookup.

Common use cases

• Fraud and risk scoring — Use country, connection type, VPN, and proxy flags to assign a risk score to sign-up or transaction events before committing them.
• Access control and geo-restriction — Block or allow access by country or region at the application layer, with fallback handling for VPN users.
• Analytics and segmentation — Enrich server logs or analytics events with country, ISP, and connection type without relying on client-side geolocation permission prompts.
• Ad targeting and compliance — Apply GDPR, CCPA, or other jurisdiction-specific rules based on the detected country of the connecting IP.
• Rate limiting and abuse prevention — Distinguish between residential, hosting, and Tor traffic to apply differentiated rate limit policies or CAPTCHA challenges.
• Content personalisation — Serve localised content, currency, or language defaults based on country and region detection without requiring the user to specify their location.

Example API response

{
  "ip": "8.8.8.8",
  "country_code": "US",
  "country_name": "United States",
  "region": "California",
  "city": "Mountain View",
  "latitude": 37.386,
  "longitude": -122.0838,
  "timezone": "America/Los_Angeles",
  "asn": "AS15169",
  "as_name": "GOOGLE",
  "isp": "Google LLC",
  "org": "Google LLC",
  "connection_type": "hosting",
  "is_vpn": false,
  "is_proxy": false,
  "is_tor": false,
  "is_datacenter": true,
  "threat_score": 12
}

Limitations to be aware of

• City accuracy — City-level geolocation reflects where the block was registered or where the routing hub is located, not where an individual device physically is. City placement is not suitable as a precise physical location signal.
• CGNAT and shared IPs — Mobile and some residential carriers use carrier-grade NAT (CGNAT), meaning many users share a single public IP. Individual-level attribution is not possible from IP alone in these cases.
• VPN coverage gaps — New VPN exit nodes and recently provisioned infrastructure may not appear in the database until the next update cycle. Treat is_vpn: false as "not detected" rather than "confirmed not a VPN".
• IPv6 precision — IPv6 city-level accuracy varies more than IPv4 in regions with newer IPv6 deployments and less granular registry records.

Related coverage pages

• Global Coverage — Geocoding admin depth by region, waterways, elevation
• Australian Geocoding Coverage
• UK Geocoding Coverage
• USA Geocoding Coverage
• Singapore Geocoding Coverage
• Irish Geocoding Coverage