How accurate is IP geolocation?

Where the estimate comes from

There is no location field in an IP packet. Geolocation providers build estimates from registry records stating which organisation holds an address block and in which country, from routing data showing where a block is announced, from latency measurements, and from any location information an operator chooses to publish — RFC 8805 defines a format for exactly that kind of self-published geofeed.

All of these describe the network. None of them measure the device. The result is an inference with an error range that the tidy city name in the output rarely communicates.

Registration is not location

An address block registered to a company headquarters may be used a thousand kilometres away. Operators reassign blocks between regions, acquisitions move records without moving equipment, and some databases fall back to a country-level or even arbitrary central coordinate when they have nothing better. That last habit has caused real harm to people living at the default coordinates a provider chose.

Common sources of error

Several ordinary network arrangements break the assumption that an address sits near its user.

• VPNs and proxies: the location reported is the exit server's, which is rather the point of using one.
• Mobile networks: traffic is often routed through a small number of regional gateways, so a phone can appear in a different city or country from where it is being used.
• Carrier-grade NAT: one public address represents many subscribers spread across a wide area, so any single location is a compromise.
• Satellite and business connectivity: addresses may come from a national or continental pool with no regional detail at all.
• Corporate VPNs and backhaul: a remote worker's traffic can emerge at the company's main office.

Visitor location versus server location

It is worth separating two very different questions. Geolocating a visitor's address estimates where that visitor's network is. Geolocating a server's address — a content delivery network edge, for instance — estimates where that piece of infrastructure is, and CDNs deliberately operate in many places at once.

Anycast, described in RFC 4786, sharpens the point: the same address is announced from many locations simultaneously, and routing decides which one you reach. Asking where an anycast address is has no single correct answer. So the location of the CDN edge you happened to connect to is a fact about the CDN, not about you — and conversely, geolocating your address says nothing about which edge served you.

How to read a result

Country-level accuracy is generally good, and providers publish figures in the high nineties for it. City-level accuracy is decent on fixed residential connections and unreliable on most others. Anything more precise than a city should be treated as a guess with a wide margin.

An IP-derived location is never a street address and should never be used as one. If a service acts on your apparent location, it is acting on an estimate of your network's position — which is exactly why the answer sometimes looks so obviously wrong.