How Does IP Geolocation Actually Work?

Type your IP address into any geolocation tool and within a second it returns a city, a country, latitude and longitude coordinates — sometimes even a map pin. It looks authoritative. It feels precise. But if you check the result against where you're actually sitting, there's a good chance the city is right but the coordinates point to a park, a highway, or the middle of a lake.

That's not a bug in the tool. It's a feature of how IP geolocation works. The technique is powerful and surprisingly accurate at the country level, less reliable at the city level, and almost entirely guesswork at the neighbourhood level. Understanding why requires a small detour through how IP addresses are assigned in the first place.

An IP address doesn't contain a location

This is the core thing to hold on to: an IP address is a routing label, not a geographic marker. The number 93.184.216.34 doesn't encode "Norwell, Massachusetts" any more than a phone number encodes a city. Location has to be inferred from external data, and that inference involves several layers of progressively less reliable evidence.

If you're new to what IP addresses are in the first place, the complete guide to IP addresses covers the fundamentals. The short version: every packet on the internet carries a source and destination address so routers know where to forward it. Geolocation takes that source address and asks: where, physically, is the device that sent this?

The five registries that own the address space

The internet's address space — the full range of possible IP addresses — is managed by five Regional Internet Registries, one for each major part of the world:

• ARIN — North America (United States, Canada, many Caribbean territories)
• RIPE NCC — Europe, the Middle East, and Central Asia
• APNIC — Asia-Pacific
• LACNIC — Latin America and the Caribbean
• AFRINIC — Africa

When an ISP or company needs a block of IP addresses, they apply to their regional registry. The registry records the applicant's country and organization name against the allocated block, and that record is publicly searchable. This is the first data point in any geolocation lookup: the registry assignment, which tells you the country and organization that officially holds the block.

Registry data is reliable for country-level assignment. It's less useful for telling you where the address is actually being used, because a large ISP might be assigned a block at their headquarters in one city and use it to serve customers spread across an entire region.

BGP routes and autonomous systems

The second layer comes from how ISPs actually announce their addresses to the world. Every ISP has an Autonomous System Number (ASN) — a unique identifier for a collection of IP networks under common administration. When an ISP wants traffic to reach their addresses, they broadcast routing information to the global routing table using a protocol called BGP (Border Gateway Protocol).

In simplified terms: your ISP tells every other router on the internet "to reach these IP prefixes, route traffic to my ASN." Geolocation databases ingest these BGP announcements continuously, building a real-time picture of which IP blocks are being routed through which networks. You can see this data in action — paste any IP prefix like 192.0.2.0/24 into our CIDR calculator to explore the range, or look up any IP's ASN via the IP lookup tool.

BGP data helps refine the picture because routing paths carry geographic signals. If traffic to an address consistently traverses routers in Chicago, that's weak evidence the endpoint is near Chicago. But it's weak. ISPs route traffic based on capacity and cost, not geography, so a user in rural Wisconsin might have their traffic routed through Chicago infrastructure and look, to the BGP observer, like they're in Chicago.

Why country is easy but city is hard

Combine registry data with BGP routing information and you get reliable country-level geolocation. You know which country's registry issued the block. You know which networks it routes through. Country-level accuracy for commercial geolocation databases is around 99% — it's nearly always right.

City-level is much harder. An ISP might run a network operations center in Denver and use addresses registered there to serve customers in Colorado, Wyoming, and New Mexico. The addresses say "Denver." The users might be anywhere in a 500-mile radius.

The addresses assigned to any given user are drawn from a pool the ISP manages for a whole region, not for a specific city. Without additional signals, the geolocation database can only pin you to the general area where your ISP operates — not the street you live on, and often not even the city.

How commercial databases get more precise

This is where it gets interesting. Companies that sell geolocation data — MaxMind, IP2Location, and others — don't stop at public registry and routing data. They aggregate several other signals to sharpen city-level estimates.

Latency triangulation. By measuring round-trip times from multiple servers with known locations to a target IP address, you can estimate how far away it is from each server. If a server in New York responds in 5ms, one in Chicago in 18ms, and one in Boston in 3ms, the target is probably somewhere near Boston. Do this at scale with servers distributed globally and you can narrow down a location to a metropolitan area.

Mobile SDK data. Hundreds of smartphone apps include third-party analytics and advertising SDKs that, with location permission, collect the device's GPS coordinates alongside its current public IP address. That pairing — "this phone was at coordinates 40.71°N, 74.00°W while using IP 73.16.224.18" — goes into a database. Aggregate millions of such pairings over time and you have a much more precise picture of where any given IP block is used. This is why city-level accuracy is significantly better in densely populated areas with high smartphone adoption: more data, more coverage.

WiFi mapping. Mobile devices constantly scan for nearby WiFi networks. Companies like Google and Apple have spent years building databases that map WiFi network identifiers (BSSIDs) to physical locations — partly through the infamous "Street View Wi-Spy" data collection, partly through opted-in location services. This BSSID mapping can sometimes resolve an IP location to a specific building or city block.

ISP partnerships. Some geolocation vendors purchase data directly from internet service providers — subscriber records mapped to IP allocations. This is the most precise source but also the most expensive, legally contentious, and geographically patchy.

The location on your IP lookup result is a probability estimate, not a fact. The confidence interval is measured in miles, not metres.

Where it breaks down

Even with all those signals, three categories of traffic reliably defeat city-level geolocation.

VPNs. When you connect through a VPN, every site sees the VPN server's IP address, not yours. The geolocation of your traffic is now the geolocation of that server — which might be in Amsterdam while you're in Tokyo. This is the most common reason someone sees a wildly wrong country on their IP lookup. If you want to understand what a site actually sees when you connect, check your IP before enabling a VPN and then again after.

Anycast addressing. Some IP addresses don't belong to one physical machine — they're announced simultaneously from dozens or hundreds of locations worldwide, with routing sending each request to the nearest instance. Google's DNS server 8.8.8.8 is the canonical example. Most geolocation databases resolve 8.8.8.8 to Mountain View, California — the address is registered to Google's headquarters. But when your computer sends a DNS query to 8.8.8.8, it's almost certainly answered by a Google server in your own city or region, not in California. The "location" in the database is a legal and administrative fiction, not a physical one.

Mobile carrier networks. Cellular carriers frequently route traffic from large geographic areas through centralized network hubs. Verizon might handle mobile data traffic for the entire southeastern United States through infrastructure in Atlanta. A user in Miami checking their IP might see "Atlanta, GA" as their apparent city — not because they're in Atlanta, but because their carrier's traffic exits to the internet there. Mobile geolocation is consistently the least accurate category.

IPv6. The enormous IPv6 address space, combined with the relative newness of widespread deployment, means the probe-network techniques that work for IPv4 are still catching up. If your device is using an IPv6 address, expect geolocation results to be less precise and less reliable than for IPv4.

The real accuracy numbers

Here's a rough consensus from published accuracy benchmarks across major geolocation providers:

• Country level — ~99% accuracy. Almost always correct.
• State or region — 75–90% accuracy. Usually right, occasionally off by a state or province.
• City — 50–70% accuracy, heavily dependent on geography. Urban areas in North America and Western Europe are better mapped than rural areas or the developing world.
• Street or neighbourhood — meaningless as a general capability. Any tool claiming street-level accuracy from IP alone is either lying or drawing on mobile SDK correlation data, which has serious privacy implications and spotty coverage.

When a geolocation result shows coordinates like 37.4056, -122.0775 (which resolves to a specific location in Mountain View), that's not actually saying "your device is at these coordinates." It's typically the centroid of the ISP's service area, or the default coordinates for an IP block whose location couldn't be resolved more precisely. The precision is false. The number of decimal places is not evidence of accuracy.

What this means for privacy

The good news for privacy: inexact geolocation is a structural feature, not a gap waiting to be closed. The address-to-location mapping will never be perfectly precise for the fundamental reason that addresses are assigned by administrative region, not by GPS coordinate.

The more unsettling angle is the mobile SDK data collection. Every app you grant location permission to is a potential contributor to geolocation databases. The app itself might have a legitimate use for your location — navigation, weather, local search. But the SDK embedded in it might be collecting your GPS coordinates alongside your current IP address and selling that pairing to data brokers. Millions of such pairings over time make city-level IP geolocation progressively more accurate for everyone.

If you want a site not to know your country at all, you need a VPN or Tor. If the result is just wrong about your city, that's IP geolocation working as designed — imprecisely — and the inexactness is, incidentally, a small privacy benefit.