The real accuracy of IP geolocation at country, city, and coordinate levels β and how to account for its limitations in your applications.
IP geolocation accuracy is one of the most frequently misunderstood aspects of internet infrastructure. Vendors who sell geolocation data often quote impressive accuracy figures; users who've been wrongly identified often feel the service is completely broken. The truth is more nuanced β accuracy varies enormously by location specificity level, country, network type, and the time since the database was last updated. Understanding the real numbers helps you build better applications and set appropriate expectations for what geolocation can and can't tell you.
The most important principle in IP geolocation: accuracy degrades dramatically as you request more specific information. A database that's 99% accurate at the country level might be 50% accurate at the city level for the same IPs.
Country accuracy: 95β99%
Country is the most reliable level of geolocation. IP address allocation is documented at the country level in RIR records, BGP announcements are tagged by country, and most IP blocks don't span national borders. Errors at this level typically involve:
State / Region accuracy: 55β80%
Regional accuracy is considerably lower and highly variable. An IP from a California ISP might geolocate to California 80% of the time, but ISP routing arrangements mean some traffic exits through another state's infrastructure. Rural areas are particularly hard β a user in a rural county might have their traffic routed through the nearest metropolitan area, which can be in a different state.
City accuracy: 50β75%
City-level accuracy depends heavily on which country and which ISP. Major metropolitan areas in countries with good data coverage (US, UK, Germany, Japan, Australia) typically have 65β75% accuracy. Rural areas in any country, and urban areas in countries with less data coverage, often fall below 50%. The vendor's benchmark figure is typically the average across their entire database, which is weighted toward well-mapped areas.
Postal code accuracy: 30β50%
Postal codes are too granular for IP-based geolocation to handle reliably. Different databases will often return different postal codes for the same IP, because the underlying data simply isn't precise enough at this level. Use this only as a very rough guide.
Coordinate accuracy: Often misleading
IP-derived coordinates are frequently the geographic centroid of a city, the location of the ISP's NOC (network operations centre), or the location of a regional routing hub β not the actual device location. A user in London might geolocate to coordinates that map to Ipswich because their ISP's East Anglia gateway is there. Never display IP-derived coordinates on a map to end users as if they represent their actual location.
Different categories of internet connection produce systematically different geolocation accuracy:
Fixed-line residential DSL/cable tends to geolocate relatively accurately because the IP block is associated with a specific geographic exchange or DSLAM. Comcast subscribers in downtown Chicago are typically served by IP blocks associated with the local headend.
Mobile networks are significantly less accurate because mobile carriers use centralised gateways. A user anywhere in the UK on EE might exit through a gateway in London, appearing to be in London regardless of their actual location. This is a systemic feature of mobile IP architecture, not a database error.
Satellite internet (Starlink in particular) often geolocates to the ground station rather than the user. Ground stations are fixed points that may be hundreds or thousands of miles from subscribers. Starlink users in remote areas often geolocate to the nearest ground station city.
Carrier-Grade NAT (CGNAT) further reduces accuracy. When an ISP uses CGNAT to share a single public IP among hundreds of subscribers across a region, the associated IP block reflects the regional gateway, not any individual subscriber's physical location.
Corporate and enterprise connections often route all traffic through central offices or cloud gateways. An employee working from home in Manchester might appear to be in London where the company's internet gateway is located.
Building robust applications around imperfect geolocation data requires a few key practices:
Use it as a signal, not a ground truth. Geolocation data should inform your systems, not determine hard outcomes unilaterally. Combine it with other signals: user-reported location, browser language, timezone, billing address.
Provide appeal paths for false positives. If you use geolocation for access control, always give legitimate users a way to verify their identity and override an incorrect geo-block. A user in a licensed country who geolocates incorrectly shouldn't be permanently blocked.
Match specificity to use case. Use country-level data for country-level decisions. Don't make city-level decisions based on city-level data without acknowledging the substantial error rate.
Keep your database fresh. A geolocation database that hasn't been updated in months will degrade in accuracy as IP blocks are reallocated and ISP routing changes. The major providers update their databases daily to weekly from live sources.
Need proxy detection, VPN detection, or abuse scoring in your own application?