You probably interact with IP geolocation a hundred times a day without thinking about it. Netflix shows you regional content. Your bank flags a login from a different country. An online store displays prices in your local currency. A weather app guesses your city before you've even given it permission.
Behind all of that sits a quietly imperfect technology that gets things wrong way more often than the marketing pages admit. The honest answer to "where is this IP located" is almost never a single point on a map. It's a probability distribution across a region, with confidence levels that vary wildly depending on the network, the provider, and how recently somebody updated the underlying data.
This is the actual story of how IP geolocation works. The data sources, the accuracy numbers nobody likes to quote, the spectacular failures, and why your VPN sometimes shows you in a city you've never been to.
What IP geolocation actually is (and isn't)
IP geolocation is the process of mapping an IP address to a physical location. That sounds simple. Its not.
The thing most people miss is what "location" actually means here. IP geolocation does not show you where the device is physically sitting. It shows you where the IP address was registered, or where the network it belongs to routes traffic. Those are different things, and the gap between them is where almost every accuracy problem comes from.
Compare three technologies people often confuse:
- GPS geolocation: Reads satellite signals on the device itself. Accurate to a few meters when it works. Requires the device to participate.
- HTML5 Geolocation API: A browser feature that asks the user for permission, then combines GPS, Wi-Fi, and cell tower data. Accurate but requires consent.
- IP geolocation: Looks up the IP address in a database of network registrations. Doesn't need permission, doesn't need GPS, but is much less precise.
When a website shows you the right currency without asking, it's IP geolocation. When Google Maps shows your blue dot moving down the street, it's GPS. They're not the same thing.
The data sources behind every IP geolocation lookup
This is the part most articles skip over with vague language like "specialized databases". Lets actually break down where the data comes from. There are roughly seven inputs feeding any serious IP geolocation database.
WHOIS and RIR allocation records. The five Regional Internet Registries (RIPE in Europe, ARIN in North America, APNIC in Asia-Pacific, LACNIC in Latin America, AFRINIC in Africa) maintain authoritative records of which organization owns which IP block. These records include a country code and contact details. They are the foundation, but they're often stale. An ISP might have been allocated a /16 in 2003 and still uses some of those addresses in cities they didn't serve back then.
BGP routing announcements. Networks announce to the global internet which IP prefixes they're routing for. These announcements travel through Border Gateway Protocol, and you can see them by querying public route collectors like RouteViews or RIPE RIS. BGP data tells you which network is currently handling an IP, even if the registration says somthing different.
Geofeeds (RFC 8805). This is a relatively new and underused mechanism. Network operators can publish a CSV file at a known location describing exactly which IPs go where, down to city level. The standard was published in 2021. As of 2024, only about 1.5% of allocated IPv4 prefixes had a geofeed. Slow uptake, but the operators who do publish them produce the most accurate data available, because it's coming straight from the source.
ISP self-reporting. Some ISPs send geographic data directly to geolocation providers under contract. This is reliable when it happens, but inconsistent across the industry.
Active probing. Networks like RIPE Atlas have thousands of probes around the world that measure latency to IP addresses. If an IP responds to your probe in 2 milliseconds, it's nearby. If it takes 200 milliseconds, it's on another continent. By triangulating latency from multiple probes, you can estimate location even when registration data is missing.
DNS hostnames. Many ISPs encode location information in their reverse DNS hostnames. Something like host-1-2-3-4.lon01.example.net tells you the IP is in London if you know the convention. Different ISPs use different patterns, so this requires constant pattern matching and is more art than science.
User-submitted corrections and crowdsourced data. When users report wrong locations to providers, that feedback gets folded back into the database. This is the messiest input but sometimes the most current.
A serious geolocation database doesn't pick one of these. It combines all of them, weighs them by confidence, and reconciles conflicts. At ipwhois.net we pull from RIR allocation records, BGP announcements, published geofeeds, and our own active measurements, then cross-validate before publishing a result. When the inputs disagree (which happens more than you'd think), the accuracy goes down and we mark the result as lower confidence.
How accurate is IP geolocation, really?
Here are the numbers most providers will quote, and they're roughly right:
- Country level: 95-99% accuracy
- Region or state level: 55-80% accuracy
- City level: 50-75% accuracy
- Postal code or street level: not reliable, full stop
But these numbers are averages, and averages hide everything interesting. The variance is huge.
In a major urban area like London or New York, city-level accuracy can hit 85% or higher. In rural Montana or central Australia, it drops below 40%. Mobile networks are worse than residential broadband by a wide margin. ISPs that publish geofeeds are dramatically better than ones that don't. Databases that update daily are better than ones that update monthly, and a surprising number of "premium" services in this space update only quarterly.
There's also a "country accuracy" issue people don't talk about. The 95% country accuracy figure means 5% of IPs get the wrong country, which sounds small until you realize that's tens of millions of addresses. For fraud detection, ad targeting, or content licensing, that 5% is a big deal.
Why your IP location is often wrong
If you've ever checked your IP on a lookup tool and seen a city you've never visited, here's what's probably happening.
Mobile networks bind to gateway locations. When you're on 4G or 5G, your phone doesn't get a public IP that's geographically near you. It gets routed through a carrier gateway, sometimes hundreds of kilometers away. A user in Manchester might appear to be in London because that's where Vodafone's mobile gateway sits. T-Mobile in the US famously has gateways that put millions of users in just a handful of cities, regardless of where they actually live.
CGNAT pools share addresses across regions. Carrier-Grade NAT lets ISPs put thousands of customers behind a single public IP. The location of that public IP is wherever the ISP registered it, not where any individual user is. If your home internet is on CGNAT (most mobile and a lot of cable connections in 2026 are), the IP shown for you is shared with hundreds of strangers, possibly in a different city or country.
Corporate VPNs route everyone through one place. A consultant in Berlin connecting to her company's VPN appears to be in Frankfurt because that's where the VPN exit lives. Same for remote employees of multinationals who tunnel through HQ.
Database staleness. Some geolocation providers refresh their data monthly or quarterly. ISPs reassign IP ranges between cities all the time. The result is a lookup that says Hamburg when the IP has been routing traffic in Munich for the last six weeks.
ISP recycling without updating WHOIS. RIRs require contact updates but don't actively police geographic accuracy. An ISP might internally move a /22 from one city to another and never bother to update the registration. The geolocation provider has no way to know.
Geofeed lag. Even when geofeeds exist, providers don't all consume them on the same schedule. A geofeed published Monday might not show up in some commercial databases until the following month.
The Potwin Kansas problem (and other infamous failures)
This is the famous story that should be required reading for anyone using IP geolocation in production.
In 2002, MaxMind started building one of the first commercial IP geolocation databases. For IP addresses where they had a country (United States) but no specific location, they needed a default. They picked the geographic center of the contiguous United States: latitude 38.0000, longitude -97.0000.
That coordinate happens to fall on a small farm near Potwin, Kansas, owned by Joyce Taylor and her family. Over the next 14 years, roughly 600 million IP addresses got mapped to her farm whenever any service couldn't pinpoint them more precisely.
The result was relentless. The Taylors had FBI agents show up looking for stolen identity perpetrators. IRS investigators came hunting tax fraud. Ambulances arrived for fictional suicidal women. Strangers showed up accusing them of running scams, hosting child abuse content, and stealing emails. Sheriffs visited regularly. They were threatened by people who had been defrauded online and traced the perpetrator to a coordinate that landed on their property.
Wrong IP Geolocation simulation, image created by AI grok
In 2016, journalist Kashmir Hill broke the story for Fusion. MaxMind responded by changing thier default coordinates for IPs they couldn't precisely locate. They moved the US default into the middle of a lake near Wichita, and made similar changes for other country defaults to avoid pointing at any inhabited location.
The lesson is broader than one farm in Kansas. Defaults matter. When a system can't answer a question precisely, the way it handles uncertainty determines whether the wrong answer is harmless or catastrophic. MaxMind's mistake was using a precise-looking coordinate to represent imprecise data, and trusting that downstream consumers would understand the nuance. They didn't.
There are other examples. An entire town in Australia got blamed for spam from a misconfigured /24 mapping for years. Several US Census coordinates have caused similar problems for the people unlucky enough to live near them. Geolocation defaults are still a quiet source of harm, especially when fraud detection systems treat a coordinate as a fact rather than an estimate.
Network type changes everything
Different kinds of networks behave so differently that you almost need to think of them as separate problems.
Mobile networks (4G, 5G, LTE) are the worst. Carriers operate a small number of gateway POPs that aggregate traffic from huge regions. Geolocation can usually identify the carrier and country with high confidence, but the city-level result is often the gateway city, not the user's actual location. For a UK mobile user, the answer might be London regardless of whether they're in Cardiff, Edinburgh, or Liverpool.
Residential broadband is the best case for traditional geolocation. ISPs typically allocate IP ranges by geographic region, and the WHOIS data tends to be more accurate. In urban areas you can often get city accuracy with 80%+ confidence. In rural areas it gets worse but still better than mobile.
Datacenter IPs are precise to the datacenter building, which is interesting from an infrastructure standpoint and useless for figuring out where a user is. Anyone showing up from a datacenter IP is almost certainly using a VPN, proxy, or cloud service. Treating that location as the user's location is a mistake.
Satellite ISPs like Starlink are a new and weird problem. Starlink has more than 150 sextillion IPv6 addresses and rotates traffic through ground stations that can be hundreds of kilometers from the actual user. A Starlink customer in northern Norway might appear to be in Sweden, then Latvia, then Germany, depending on which ground station handles their session. Traditional geolocation databases struggle with satellite networks because the relationship between IP and physical location is fundamentally different.
Corporate networks show the headquarters location even for remote employees. A company with 20,000 employees scattered across 30 countries can appear to traffic analytics like 20,000 users in one city.
When VPNs, proxies and Tor enter the picture
VPNs deliberately break IP geolocation. That's the whole point. When a user connects through a VPN, the IP shown to the destination is the VPN provider's exit node, which can be anywhere. Geolocation correctly identifies the exit node's location, which has no relationship to the actual user.
Detecting VPN usage is its own field. Commercial databases tag known VPN exit nodes, and the major VPN providers' IP ranges are public knowledge. Users who route through a known VPN get flagged regardless of how clean the underlying IP looks.
Residential proxies are harder. The FBI issued a public service announcement in March 2026 warning about the rise of residential proxy networks, where attackers route traffic through real home internet connections (often without the homeowner's knowledge, via SDKs hidden in apps or compromised IoT devices). To a geolocation database, this traffic looks exactly like a legitimate residential user, because it is one. The IP belongs to a Comcast customer in Atlanta. The actual person controlling the session might be in Pyongyang.
Tor exit nodes are publicly listed and easy to detect. Anyone routing through Tor knows their location is going to be wherever the exit happens to live, often a different country every time the circuit changes.
How to verify your own IP geolocation
If you're curious whether your IP is showing the right location (or wondering why some service thinks you're somewhere you're not), here's what you can do.
Run an my location and check the result. Then run the same IP on two or three other major providers and compare. If they all agree, the data is probably accurate. If they disagree, you're seeing the messy reality of this technology firsthand.
If your IP is showing the wrong location and it's affecting you (streaming services, ad targeting, fraud blocks), the only real fix has to come from your ISP. Specifically, ask them whether they publish a geofeed (RFC 8805). If they do, the wrong location can usually be corrected within a few weeks across most providers. If they don't, you're stuck waiting for various databases to refresh on their own schedules, which can take months.
For ISPs reading this: implementing a geofeed is a small amount of work and benefits all of your customers at once. There's no good reason not to do it in 2026, and most of your competitors that already publish geofeeds get noticeably better geolocation accuracy as a result.
For developers building anything that depends on IP geolocation: treat the result as a probability, not a fact. Always cross-check against other signals (browser timezone, language preferences, payment country) before making decisions that affect users. The Potwin Kansas story is what happens when systems treat geolocation as ground truth.
Wrap up
IP geolocation is one of those technologies that works well enough most of the time that people assume it always works. It doesn't. The data behind it comes from a mix of registries, routing announcements, geofeeds, and active measurements, all of which have their own staleness and error patterns. Mobile, satellite, CGNAT, and proxy traffic each break the model in different ways.
When you understand where the data actually comes from, you can build systems that handle the uncertainty instead of pretending it isn't there. And you can answer the question "why does this site think I'm in Frankfurt" without getting frustrated, because the answer is usually one of about six predictable reasons.
The goal isn't perfect accuracy. The goal is honest data with clearly understood limits, and using it appropriately for the problem you're trying to solve.
Comments 0