If you've ever booked a flight and seen prices in your local currency without choosing one, or read a news article that opened with "Hello, reader in [your city]" — that's IP geolocation. It's a quiet piece of infrastructure that powers a huge amount of personalization, fraud detection, content licensing, and security tooling on the web.

It's also routinely wrong in ways most users never notice. Understanding how it works (and how it doesn't) is useful for anyone building services that depend on it — and for anyone curious about why a website thinks they're in Topeka when they're actually in Brooklyn.

The fundamental fact: an IP doesn't carry location

An IP address is just a number. There is nothing inside 8.8.8.8 that says "this is in California." Geolocation is inference, not lookup. It works by combining several independent data sources to make an educated guess.

The two big categories of source data are:

  1. Registry information. Regional internet registries (RIRs) — ARIN, RIPE, APNIC, LACNIC, AFRINIC — assign blocks of IP addresses to organizations, and the registration records include a country and contact details. This data is public and reasonably authoritative at the country level.
  2. Operator data. ISPs and large network operators frequently publish where they route specific blocks of IPs. Some of this is contractual (large content providers and CDNs need accurate location data to direct traffic), some of it is voluntary, and some of it is observed indirectly — for example, by measuring how long it takes a packet to reach the IP from various known locations.

Geolocation database providers — MaxMind, IP2Location, ipinfo, Digital Element, and a handful of others — take these sources and add their own measurements, partner integrations, and machine learning to produce the databases that everyone else consumes.

What "accurate" actually means

Accuracy is meaningful only at the right resolution. Here's roughly what to expect from a good commercial geolocation database in 2026:

  • Country: 99%+ correct for residential and business IPs in well-mapped countries. Lower in some emerging markets.
  • Region/state: 80–90% accurate for fixed-line IPs. Much lower for mobile networks.
  • City: 50–80% accurate when given as the nearest metro. The percentage depends heavily on country and on ISP cooperation.
  • Postal code or "street address": Don't trust these. They're often guesses based on the centroid of the city or region, and they should never be treated as a real address.

Important: most databases don't tell you their confidence. They just return a row. A row that says "city: Topeka, postal: 66614" looks identical whether it's a high-confidence match or a centroid guess. Treat city-level data as a probability, not a fact.

Where geolocation goes wrong

1. Mobile carriers

Mobile networks are the worst case for accuracy. A single regional mobile data center may serve customers across thousands of square miles, all routed through the same upstream IP block. Your phone might appear at a tower fifty miles from where it's actually being held — or, with carrier-grade NAT, at the IP of a regional gateway hundreds of miles away.

If you've ever wondered why your phone's weather app keeps suggesting a city you don't live in when you let it use "location from IP" — this is why.

2. VPNs and proxies

A VPN puts an extra hop in the path. The IP the website sees is the VPN's exit node, which can be anywhere. Geolocation correctly identifies the exit node, which is usually not where the user is. Good databases flag known VPN exits and datacenter IPs, but new exits appear constantly.

3. Datacenter IPs in general

If a website thinks you're in Ashburn, Virginia, you're probably going through a cloud-hosted browser, scraping service, AWS instance, or similar. Almost no humans live in Ashburn-the-datacenter — but a huge fraction of internet traffic appears to originate there because that's where the major US-East cloud regions are.

4. Block-level rerouting

An ISP can lease or move an entire block of IPs to a new region without telling anyone outside their own network. Until the geolocation provider's measurements catch up — which might take days, weeks, or never — the database will report the old location.

5. Centroid-stuffing

When the database can identify a country or region but doesn't have city-level data, some providers fill in the centroid of the country or region as the "location." This is how a substantial number of IPs end up "located" at a literal field in the middle of Kansas, or in a lake in the middle of Australia. Famously, one farm in Kansas (Potwin) was for years the apparent home of millions of IPs simply because it was the closest point to the geographic center of the contiguous United States.

How the data is actually gathered

Commercial providers use a mix of techniques:

  • WHOIS scraping. Public registry records give country and organization for every block.
  • BGP route analysis. Looking at how IP blocks are announced globally suggests where the operator's network terminates.
  • Latency measurements. If a packet reaches the IP in 8ms from a known San Francisco probe and 110ms from a known Frankfurt probe, the IP is probably closer to San Francisco.
  • Partner data. Major ISPs sometimes provide accurate prefix-to-city mappings to a database vendor as part of a commercial arrangement.
  • User-submitted data. Some platforms (including the database vendors themselves) collect anonymized "I'm here" signals from users with GPS-enabled devices, then cross-reference these with the IPs those devices were using.
  • Machine learning models that combine all of the above into a confidence-scored estimate.

What it's used for

Even with the caveats, IP geolocation is everywhere because it's cheap and good enough for many uses:

  • Content localization. Showing the right currency, language, or product catalog.
  • Compliance. Restricting access from sanctioned countries, applying region-specific data protection rules.
  • Streaming rights. Enforcing that a movie licensed only for Germany isn't streamed to a US viewer.
  • Fraud detection. A login from an IP geographically far from the user's normal one is a useful signal — not proof of fraud, but worth a second look.
  • Analytics. Reporting on traffic by country and city.
  • Ad targeting. Showing different ads to different metros.
  • CDN routing. Sending you to the nearest server.

What to do if you build something that uses it

A few practical recommendations:

  1. Treat country as reliable, city as a hint. Don't surface city-level data to the user as if it's authoritative — and certainly don't make decisions that hurt the user when the city is wrong.
  2. Always have a manual override. Let users correct their assumed location. Pricing, currency, and language should all be overridable in one click.
  3. Use proxy/VPN/datacenter flags carefully. They're useful for fraud signals, not for blocking access wholesale (lots of legitimate users use VPNs).
  4. Refresh your data. Geolocation databases change weekly. Pin to an old version and your accuracy slowly decays.
  5. If you really need precise location, ask the user. Browser geolocation (with user permission) is far more accurate than any IP-based inference.

And if you're a user?

If a site has you in the wrong city, it's almost certainly not because your IP "knows" the wrong location — it's because the database the site uses is fuzzy at the city level for your ISP. Switching networks (e.g. mobile vs. home Wi-Fi) often produces a different guess. There's nothing personal about it.

Want to see what databases think about your IP? Run a lookup on your own IP and compare with your actual location. The mismatches are often surprising.

Related reading: What is an IP address, really? · IPv4 vs IPv6