Region and city results are a different story: usable as probabilistic signals, but variable by network type and geography. Coordinates returned by any IP lookup are a centroid with an accuracy radius, not a GPS pin, and mobile, VPN, or datacenter traffic can push the real error to the hundreds of kilometers.
TL;DR:
- Most IP geolocation data rely on registry allocations and ISP geofeeds, but coordinate precision often reflects a city centroid, not an exact device location.
- VPNs, proxies, mobile carrier NAT, and datacenter routing frequently cause geolocation results to reflect intermediary locations rather than actual user locations.
- Benchmarking accuracy requires median error, error radius, and granular metrics, with regular ground-truth testing to account for ISP reassignments and NAT churn.
- Combining passive databases with active probing improves accuracy, but mobile and rural areas remain challenging, and IP should only inform coarse decisions unless verified by user consent.
Table of Contents
- How Accurate Is IP Geolocation by Granularity?
- Where Does IP Geolocation Data Actually Come From?
- Why Do Some IP Lookups Give the Wrong Location?
- What Metrics Should You Use to Benchmark Geolocation Accuracy?
- How Do You Improve and Validate IP Geolocation in Production?
- What Does the Research Say About Hybrid Geolocation Methods?
- What's the Right Risk Posture for Engineering Teams?
- Diagnose Location Signals Before You Trust Them
- Sources
How Accurate Is IP Geolocation by Granularity?
Accuracy collapses the finer you zoom in. Country attribution sits near the ceiling of what any IP-based method can achieve, with providers like MaxMind reporting figures around 99.8% for country-level lookups. That number holds up because it's built on stable registry allocations, not inference.
Below the country level, things get murkier fast:
- Region or state accuracy varies by country and ISP reporting density, generally considered moderately reliable but variable.
- City-level accuracy varies widely based on network type and urbanization, providing a useful but imprecise signal.
- Coordinate precision is usually expressed as a radius around a centroid rather than a point, and that radius can span a few kilometers in a well-mapped city or over a hundred in a rural or mobile-heavy region.
Statistic callout: Fixed broadband connections show median location errors of roughly 3 to 16 kilometers, while mobile networks frequently show median errors between 179 and 207 kilometers. That's not a rounding difference. It's the gap between "useful for fraud screening" and "useless for anything requiring precision."
IPv6 adds another wrinkle. Coverage and historical mapping data for IPv6 blocks still lag IPv4 in many regions, so geolocation accuracy for IPv6 traffic tends to trail its IPv4 counterpart until registries and geofeed data catch up.
Where Does IP Geolocation Data Actually Come From?
Every geolocation lookup is a database query dressed up as real-time intelligence. The underlying data comes from a handful of distinct sources, each with different strengths:
- Registry allocations. IANA delegates address blocks to the five Regional Internet Registries (ARIN, RIPE, APNIC, LACNIC, and AFRINIC), which in turn assign them to ISPs and organizations. This registry chain is why country-level attribution is so dependable: allocations are recorded and audited.
- ISP geofeeds. RFC 8805 defines a simple format for ISPs to publish self-declared location data for their own address blocks. Coverage is inconsistent since adoption is voluntary, but where an ISP publishes a geofeed, the accuracy is often excellent.
- Routing and probing signals. BGP announcements narrow down which network is originating traffic for a block, while reverse DNS naming conventions and active latency probes help refine estimates when registry and geofeed data go stale or silent.
Coordinates produced this way represent a centroid of an address block or an egress point, not a device's actual GPS position. That distinction matters more than most integration guides admit.
Why Do Some IP Lookups Give the Wrong Location?
Most "wrong" geolocation results aren't bugs. They're the system correctly reporting the location of an intermediary instead of the person behind it.
VPNs, proxies, and Tor exit nodes are the clearest case: the lookup is technically accurate for the exit node, but that's rarely where the actual user sits. Corporate networks route traffic through centralized backhaul, so a company with offices worldwide might show every employee's traffic exiting from one data center.
Mobile carriers cause a different kind of damage. Carrier-grade NAT (CGNAT) means thousands of devices across a wide geographic area share a small pool of public IPs, and carriers reassign those blocks frequently. That's a direct driver of the mobile median error figures cited above, and it's also why mobile IP addresses get reassigned across wide geographic spans often enough to break any assumption of stability.
Cloud and datacenter traffic is its own category. Signs an IP belongs to a hosting provider rather than an end user include:
- ASN ownership registered to a cloud provider rather than a residential or mobile ISP.
- Reverse DNS hostnames containing patterns like "compute," "aws," or a data center's own naming scheme.
- Unusually stable, always-on connectivity with no diurnal traffic pattern.
Pro Tip: Before trusting any city or coordinate result, check the observed IP against a "what's my IP" style lookup and confirm it isn't flagged as VPN, proxy, or datacenter. If it is, fall back to region or country granularity instead of trusting the point estimate.
What Metrics Should You Use to Benchmark Geolocation Accuracy?
Serious benchmarking requires more than a single accuracy percentage. Researchers typically report median or mean error distance (how far the estimated point sits from ground truth), accuracy@radius (the share of lookups falling within a set distance, such as 50 or 161 kilometers), and precision/recall broken out by granularity to avoid letting country-level performance mask city-level failure.
Building a ground-truth dataset means pairing IP lookups against opt-in browser geolocation API results or a validated list of known-location IPs, then watching for sampling bias toward urban, fixed-line users who are overrepresented in most volunteer datasets — this is where tools like the Geo Grid Rank Tracker provide valuable local geo-testing insights.
How Do You Improve and Validate IP Geolocation in Production?
Raising effective accuracy is less about finding a better database and more about building a validation loop around whatever database you use.
- Flag every lookup for VPN, proxy, or datacenter status before trusting its coordinates, combining IP classification with ASN and reverse DNS lookups.
- When a flag fires, automatically fall back to a coarser granularity (region or country) instead of displaying a false point estimate.
- Cross-check passive database results against active signals like traceroute hop locations and latency triangulation.
- Sample daily against a ground-truth set, compute median error and the tail percentiles (95th, 99th), and alert when either degrades.
A few instrumentation habits pay for themselves quickly:
- Keep a rolling sample size large enough to detect a 10 to 15 percent shift in median error, not just gross outages.
- Refresh your ground-truth comparisons at least weekly since ISP reassignment and CGNAT churn shift the map underneath you.
- Surface the accuracy radius in your UI or logic rather than a bare coordinate, so downstream automation can make its own confidence call.
What Does the Research Say About Hybrid Geolocation Methods?
A 2025 benchmarking study found that hybrid approaches combining active probing with passive registry and database sources consistently reduce both average error and the frequency of extreme outliers compared with single-source methods. The gains are most pronounced in urban areas with dense infrastructure, where multiple signals reinforce each other.
The same body of research keeps surfacing the mobile problem: Internet Society's Pulse analysis puts mobile median error at 179 to 207 kilometers against 3 to 16 kilometers for fixed lines, a gap that no single-source method has closed. Rural regions, islands, satellite-connected areas, and parts of the Global South remain the hardest cases across nearly every study, largely because sparse ISP geofeed adoption and thin registry granularity leave less signal to work with in the first place.
What's the Right Risk Posture for Engineering Teams?
Treat IP-based location as a probabilistic signal, not ground truth. Accept it for coarse decisions like fraud screening, content localization, or analytics; require opt-in device location whenever the decision affects someone's safety, legal standing, or money. Log every flagged result, sample against ground truth regularly, and build a fallback path for low-confidence lookups. For fast manual checks, Pingfloat's diagnostic tools are worth keeping bookmarked.
— Andreas
Diagnose Location Signals Before You Trust Them
A fast way to sanity-check a geolocation result without spinning up your own probing infrastructure. When a lookup looks wrong, start with What's My IP to confirm the observed address and header details, then run Traceroute to trace the actual network path and spot datacenter or backhaul hops that explain a mismatched location.
If the anomaly turns out to be server-side rather than a bad geolocation guess, Pingfloat's Website Uptime Monitor and SSL Checker help rule out CDN routing or certificate issues that can masquerade as location errors. All of these run free, with no sign-up required for a quick check. Open What's My IP now and see exactly what your own connection is reporting.
Sources
- Why IP geolocation can’t be trusted for mobile networks and the Global South — Internet Society Pulse (2026)
- Large-Scale IP Geolocation Accuracy Assessment Using Measurement Datasets (2025)
- IP geolocation accuracy — MaxMind support/guidance