How Accurate Are IP Address Location Lookups?

Think of an IP location result as a set of nested estimates. Country is the strongest: address blocks are allocated to organisations in a specific country and rarely cross borders in use, so country results are right for the large majority of fixed broadband connections. Region or state is next, usually correct but not always. City is an estimate that is often right for cable and fibre customers in dense areas and often wrong elsewhere. Coordinates are the weakest field of all: they mark the centre of the area the database chose, not the device.

Providers that publish their own accuracy figures make the same point in numbers. MaxMind, whose databases many lookup tools use, reports high country-level accuracy and materially lower city-level accuracy, and its figures differ by country and by whether the connection is fixed, mobile or business.

Nobody measures your device. Geolocation databases are built from several indirect sources. Regional Internet Registries record which organisation holds each block and where that organisation is based. ISPs can publish geofeeds, a standard format defined in RFC 8805 that states where their ranges are used. Providers add latency measurements from many vantage points, partner data, and corrections submitted by users and network operators. Each source is approximate in its own way, and the database is a best guess that reconciles them.

Mobile networks are the most common cause. A phone's traffic exits at a carrier gateway that can be hundreds of kilometres away, and every user behind that gateway appears to be there. Carrier-grade NAT, used by mobile and many fixed ISPs, puts many subscribers behind one address.

VPNs and proxies move the apparent location to the exit server. Business and university networks are often registered at a headquarters while traffic comes from branches. Satellite services route through ground stations. And databases lag: when a block is reassigned to a new ISP or a new region, the old location can persist until the next update cycle.

Compare two independent providers; agreement on the city is reassuring, disagreement means treat it as regional. Read the ISP and connection type before the city: a mobile carrier or a hosting provider tells you the city field is not describing a home. Check whether the time zone in the result matches the region shown. Look at the region and country rather than the city when they disagree with expectations. And treat coordinates as the centre of a circle whose radius you do not know.

City-level geolocation is well suited to localisation, currency and language defaults, regional pricing, fraud context and troubleshooting where a rough location is enough. It is not suited to identifying a person, enforcing a precise boundary on its own, or deciding that a user is lying because the city differs from what they said. Read it as network context and combine it with other signals before acting.

City data earns its place as context. It helps spot a login that appears far from where an account is normally used, it localises content and pricing, and it explains traffic patterns in analytics. When a decision has consequences for a user, pair the city with stronger evidence, such as login history, device consistency and a fraud score for the address, rather than acting on the city alone.