How accurate is IP geolocation, really? (and when to reach for GPS)

"How accurate is IP geolocation?" is the wrong question. Accuracy isn't a single number you can print on a landing page — it's a curve that collapses as you zoom in, and it means something different at the country, region, and city level. The honest version is: accurate enough for *which decision?* Get that framing right and IP geolocation is one of the most useful signals you have. Get it wrong and you ship a "detected location" that quietly lies to a slice of your users on every single request.

How accuracy behaves as you zoom in

Every IP-to-location dataset is built by inference — from regional registry allocations (RIR/WHOIS), routing announcements (BGP), latency triangulation, and crowd-sourced signals — not from a GPS chip. That inference is strong for the big geographic buckets and weak for the small ones, and it drifts over time: IPv4 blocks get re-sold and re-homed between regions, and IPv6 ranges are frequently mapped more coarsely than IPv4. A working mental model of what GET /v1/geoip can actually resolve:

• Country — ~99%+. The one figure you can genuinely build on. Reliable enough to drive currency, tax region, language, and content routing without a second thought.
• Region / state — ~80–90%. Fine for analytics, regional content, and coarse fraud rules; not something to gate a legal or billing decision on by itself.
• City — commonly 50–80%, and wildly variable by country and network. Errors of tens of kilometres are normal, and worse on mobile. Treat the city as a hint, never a fact.
• **Latitude / longitude — a *centroid*, not a fix.** The coordinates point at the estimated centre of a city or postal area (sometimes literally the middle of the country when nothing better is known), not at the device. Don't render them as a map pin and imply a precision you don't have.

What a single accuracy percentage hides

When a provider advertises "95% accurate," ask *at what radius, and weighted how?* Two things get quietly folded into that number. First, radius — city-level accuracy is measured as "within X km of the true location," so 95% at a 50 km radius and 95% at a 5 km radius are wildly different products wearing the same label. Second, population weighting — benchmarks are averaged across real traffic, which is dense in well-mapped metros and sparse elsewhere, so a headline figure looks great precisely because most requests come from the places that are easiest to locate.

Your users in a smaller town or on a mobile network live in the tail that the average hides. That's why a good response hands you a confidence radius alongside the guess — and why you should treat that radius as a first-class input rather than rounding it away. A result that's "in Nuremberg" with a 5 km radius and one that's "in Nuremberg" with an 80 km radius are not the same claim, even though the city string reads identically.

A real response, and which fields to trust

Here's a representative GET /v1/geoip response. The habit worth building is reading it *by granularity*, not top to bottom:

{
  "ip": "88.198.24.7",
  "country": { "code": "DE", "name": "Germany" },
  "region": { "code": "BY", "name": "Bavaria" },
  "city": "Nuremberg",
  "postal_code": "90402",
  "location": {
    "latitude": 49.45,
    "longitude": 11.08,
    "accuracy_radius_km": 20
  },
  "timezone": "Europe/Berlin",
  "currency": "EUR",
  "network": {
    "asn": "AS24940",
    "organization": "Hetzner Online GmbH",
    "type": "hosting",
    "is_proxy": false
  }
}

• Trust for decisions — country.code, timezone, and currency. These ride on the reliable country/region layer. This is your green zone.
• Use as a hint, with the radius attached — city, postal_code, and location.*. Read accuracy_radius_km *every time*: a 20 km radius means "somewhere in greater Nuremberg," not a specific street. Never surface the coordinates as an exact address.
• Read as a warning flag — network.type and is_proxy. Here type: "hosting" says this IP belongs to a datacentre (Hetzner), not a home broadband line — a strong signal the "location" is an exit node, not a person sitting in Nuremberg.

What actually degrades it

The gap between the headline number and your real result is almost always one of these. None are edge cases anymore — together they're a large share of live traffic:

• VPNs and proxies resolve to the exit node's location, not the user's. This is mainstream consumer behaviour now, and to your API it's invisible unless you check the proxy/network signal.
• Mobile carriers and CGNAT route thousands of subscribers through a handful of regional gateways. A phone can surface hundreds of kilometres from the handset, and one IP can represent users across a whole region.
• Corporate egress sends an entire distributed workforce out through one or two HQ IPs — everyone "in" the head-office city regardless of where they actually sit.
• IP reassignment and allocation churn — address blocks are bought, sold, and re-allocated between regions; databases lag reality by days or weeks, so a "wrong" answer is often just a stale one.
• Satellite and roaming — satellite ISPs and international roaming can anchor a user to a gateway country entirely unrelated to where they're standing.

What it's good for — and what it isn't

Once you accept the granularity curve, the right uses are obvious. IP geolocation shines when the decision tolerates a city-level miss and benefits from being instant and permission-free:

• Currency and pricing — pick a sensible default from country.code; let the user override it.
• Content and language localization — region-aware copy, language, and regulatory notices.
• Fraud and risk signals — proxy/hosting flags, country mismatches, and impossible-travel checks are some of the highest-value uses of IP data.
• Compliance region — deciding which tax, consent, or data-residency rules apply.

It's the wrong tool the moment a real-world *point* is at stake:

• Delivering to a door, dispatching a driver, or dropping a map pin — that needs a device fix, not a centroid.
• Emergency or safety-critical location — never lean on IP where being tens of kilometres off has real consequences.
• Anything you'd stake a legal or financial outcome on at street level.

When to reach for GPS

When you genuinely need street-level precision, the honest answer is device coordinates the user has agreed to share. That's what GET /v1/geocode is for: you pass consented latitude/longitude from the browser or device (the Geolocation API, after a permission prompt) and get back a structured address, place, and administrative hierarchy — a real fix, not an inference.

The two are complementary, not rivals, and the strongest pattern uses both in sequence: lead with IP, upgrade to GPS only when it earns the prompt. IP runs server-side on the very first request — no permission, no latency — enough to set currency, language, and a default region before the page even renders. Then, only on the screens that truly need a precise point (checkout address, store locator, "near me" search), ask for GPS. You get a frictionless baseline for everyone and true precision exactly where it's worth interrupting the user. Cache the coordinates a user grants so you ask once rather than on every visit, and always keep a graceful path for the majority who decline — the IP baseline is that fallback.

Drive money and locale off the country field, treat the city as a hint with its radius attached, watch the network flags for proxies — and ask for GPS only when a real-world point is genuinely worth the permission prompt.

— The rule of thumb