How IP Geolocation Actually Works

How does IP geolocation work?

An IP address contains no coordinates. There is no GPS chip in the protocol, no latitude field in the packet header, no beacon that reports where a machine sits. An IPv4 address is 32 bits of routing information; an IPv6 address is 128. Everything a geolocation service tells you about place is inferred from evidence that surrounds the address, not read out of it. Understanding how that inference works — and where it breaks — is the difference between using a tool like the tracer well and misreading its output.

The short answer to the question "how does IP geolocation work" is this: databases correlate several independent public signals about a block of addresses, weigh them against each other, and publish a best estimate with a confidence level. The long answer is worth walking through layer by layer.

Layer one: registry records

Every public IP address is allocated by one of five Regional Internet Registries: ARIN (North America), RIPE NCC (Europe, the Middle East and Central Asia), APNIC (Asia-Pacific), LACNIC (Latin America and the Caribbean) and AFRINIC (Africa). Each registry publishes who holds which block, and the registrant's country of record. This is the bedrock signal: it is authoritative, public and rarely wrong at the country level for addresses that stay where they were allocated. It says nothing about cities, and it says nothing about where individual customers of the registrant are — a national ISP's entire allocation carries one registrant address. The registry also ties each block to an Autonomous System, which is why an ASN lookup is often the most reliable part of any trace.

Layer two: ISP-published data

Some network operators publish their own geolocation data voluntarily. The standardized form is a geofeed — a CSV file, described in RFC 8805, that maps address ranges to a country, region and city. When an ISP maintains an accurate geofeed, database vendors treat it as high-confidence input, because the operator knows better than anyone which prefix serves which metropolitan area. Coverage is uneven: large content networks and forward-looking ISPs publish feeds; many operators publish nothing, and a few publish stale ones.

Layer three: latency measurement

Light in fibre is bounded by physics. If a probe server in Frankfurt reaches an address in 4 milliseconds, that address cannot be in São Paulo. Vendors run measurement networks that ping address ranges from dozens of vantage points and triangulate: each round-trip time draws a maximum-distance circle, and the intersection of many circles constrains the plausible area. Latency triangulation is good at ruling regions out and mediocre at pinning cities down, because routing detours, queuing delay and last-mile technology all inflate round-trip times unpredictably.

Layer four: crowdsourced GPS correlation

The most granular signal comes from devices that report both things at once. Mobile applications and websites that request location permission observe a GPS fix and the public IP it arrived from; aggregated across millions of consenting sessions, this builds a statistical map of which address ranges appear in which neighbourhoods. It is powerful and perishable: ISPs reassign address pools, and a block that clustered in one suburb last quarter may serve a different one today. It is also, importantly, aggregate data about ranges — it does not and cannot identify the individual behind any single address, a point covered in more depth in whether an IP reveals your address.

Layer five: hostname hints

Network engineers name routers after places. A reverse DNS lookup on a backbone hop often returns something like lon-edge-02.example.net or ae1.cr2.ord7.example.net — airport and city codes embedded by convention (LON for London, ORD for Chicago). Parsing these hostnames locates infrastructure, and an end-user address routed through a named point of presence is probably served from nearby. The signal is circumstantial: naming conventions vary by operator, names outlive relocations, and the customer may sit hundreds of kilometres from the edge router that serves them.

Why the answer is an estimate, not a fix

No single layer is decisive, so vendors combine them. Where the layers agree — registry country matches latency constraints, a geofeed names the same city the GPS clusters suggest — confidence is high. Where they conflict, the estimate widens. This is why an honest result always carries a confidence radius rather than a pin: the output means "this range most probably serves this area", never "this device is at these coordinates". Measured accuracy reflects that structure: country-level answers are right roughly 95 to 99 percent of the time, region-level answers 55 to 80 percent, and city-level answers 50 to 75 percent on fixed broadband — with mobile carriers, VPN exits and satellite links frequently wrong at every level. The full numbers are in how accurate is IP geolocation.

How the databases are compiled

Products such as DB-IP (which powers Uplink Trace's location layer) and MaxMind's GeoLite2 ingest all five layers continuously, resolve conflicts algorithmically, and publish snapshots — typically monthly for free editions, more often for commercial ones. The update cycle matters because the internet's address map moves underneath it. When a block is sold, leased or re-announced from a new country, every database that has not yet re-observed it keeps reporting the old location. Stale allocations are the single most common cause of a wrong-country result: an address range transferred from a European broker to an Asian cloud operator can geolocate to the wrong continent for months. Checking the announcing network — see what an ASN is — often exposes the mismatch, because BGP announcements update in minutes while geolocation snapshots update in weeks.

To see the layers assembled into a live dossier, run the example trace of 8.8.8.8: registry data, AS operator, reverse DNS and the geolocation estimate appear side by side, each labelled with what it can and cannot claim. That transparency is the point. IP geolocation is a well-calibrated statistical instrument for placing networks in approximate regions — and a categorically wrong instrument for locating people, which it cannot do.