How accurate is IP geolocation? The honest answer has two parts: country-level lookups are highly reliable, and city-level lookups are educated estimates. Anyone selling you "pinpoint accuracy" from an IP address alone is overselling, and understanding why makes you a much better consumer of this data.
This post explains where the data comes from, why the country is trustworthy while the city is fuzzy, what the latitude and longitude in a response actually represent, and how to design your product so the inherent uncertainty never bites you.
Why Country-Level Accuracy Is So Good
Every public IP address on the internet was allocated by one of five Regional Internet Registries (RIRs):
- ARIN - North America
- RIPE NCC - Europe, the Middle East, and Central Asia
- APNIC - Asia-Pacific
- LACNIC - Latin America and the Caribbean
- AFRINIC - Africa
Each RIR publishes delegated statistics files listing which address blocks were allocated to which country. This is not guesswork or crowdsourcing - it is the registry's own record of who received the addresses. Geolocation providers, including The IP API, build their country mapping on top of this authoritative allocation data.
That is why the country field in a lookup is dependable for the overwhelming majority of addresses. The main exceptions are worth knowing:
- Multinational networks. A company can be allocated addresses in one country and deploy them in another. Large cloud and content networks move address space between regions as capacity demands.
- VPNs and proxies. The lookup is accurate for the VPN exit server, which is exactly where the traffic really enters the public internet - it just is not where the human is sitting. Spotting these cases is a solvable problem in its own right - see How to Detect VPNs, Proxies, and Datacenter IPs.
- Recently transferred blocks. Address blocks get sold and transferred between organizations, and registry records can lag reality briefly.
None of these make the data wrong in a strict sense. The IP genuinely is announced from where the records say. The gap, when there is one, is between "where the network is" and "where the person is."
Why City-Level Is an Estimate
City-level geolocation is a different problem entirely. The RIRs record which organization received a block, not which street cabinet it terminates at. Everything below country level is inference, and several forces work against precision:
- ISPs assign addresses dynamically. A residential ISP holds large regional pools and hands addresses to subscribers as needed. The same address can serve a customer in one city today and a different city next month. No external database can track that churn in real time.
- WHOIS granularity is coarse. Registration records typically list the organization's registered address - often a headquarters or a regional office - not the physical location of each subnet. A block registered to an ISP's head office can serve customers hundreds of kilometers away.
- Mobile carriers and CGNAT. Mobile networks and many fixed-line ISPs use carrier-grade NAT, so thousands of subscribers across a wide area share a small set of public addresses. The best any database can do is place that shared address somewhere within the carrier's footprint.
- VPNs, proxies, and corporate networks. Traffic from a corporate office in one city frequently egresses through a gateway in another. VPN users appear wherever their exit node lives.
There is a genuine improvement mechanism here: geofeeds, standardized in RFC 8805. A geofeed is a CSV file that a network operator publishes describing where their own prefixes are actually deployed. Because it comes from the operator - the only party that truly knows - it is the highest-quality city-level signal available, and providers that ingest geofeeds correct exactly the cases WHOIS gets wrong. The IP API ingests RFC 8805 geofeeds as an override layer on top of registry data. Coverage is growing, but publishing a geofeed is voluntary, so it improves accuracy where it exists rather than guaranteeing it everywhere.
Because assignment practices, CGNAT prevalence, and geofeed adoption vary enormously between countries and between ISPs, honest providers do not quote a single global "city accuracy" percentage - and you should be skeptical of anyone who does without describing their methodology.
What the Coordinates Actually Mean
This is the most misunderstood part of any geolocation response. When a lookup returns:
{
"location": {
"city": "Mountain View",
"country": "United States of America",
"country_code": "US",
"latitude": 37.386,
"longitude": -122.0838,
"region": "California",
"timezone": "America/Los_Angeles"
}
}
the latitude and longitude are a representative point for the estimated area - typically the center of the resolved city or region. They are not the location of a device, a router, or a person. If the database can only resolve an address to a country, the coordinates may be a point chosen to represent that entire country.
Treating these representative points as literal street addresses has caused a famous class of real-world problems. When a default point for a large country happens to fall on someone's rural property, every IP that resolves only to "that country" appears to live there. The most widely documented case involved a farm in Kansas that sat near a default United States centroid and received years of misdirected visits from people convinced their stolen device or online harasser was physically at that address. The database was not lying - it said "somewhere in the United States" in the only vocabulary coordinates allow - but downstream users read precision into a number that never carried it. Mapping providers have since moved such default points into lakes and other unpopulated locations, which tells you everything about how these coordinates should be interpreted.
The practical rule: coordinates answer "roughly which area," never "which building."
So How Should You Actually Use It?
Match the decision to the accuracy tier:
Use country-level data for real decisions. Compliance and sanctions screening, regional pricing and licensing, tax jurisdiction hints, content rights, default language and currency - all of these operate at country granularity, which is exactly where IP geolocation is strong. This is why the country_code field, not the coordinates, does most of the commercial work.
Treat city and region as helpful defaults. Pre-filling a city in a form, picking the nearest warehouse or PoP, localizing weather - excellent uses, because a wrong guess costs the user one correction. Always let the user override it.
Use coordinates for map centering and distance estimates only. Center a map, estimate shipping zones, compute rough distances between two logins. Never render them as "this user is at this address."
Never use IP geolocation for emergency services or life-safety decisions. Emergency location has dedicated infrastructure for a reason. An IP-derived location is an estimate with unbounded error in the worst case, and nothing safety-critical should depend on it.
A related field that is often more actionable than the city is the ASN - the network operator behind the address. Knowing an IP belongs to a residential ISP, a mobile carrier, or a cloud provider tells you a lot about how far to trust the location estimate; a datacenter ASN means the coordinates describe a server rack, not a person. If ASNs are new to you, What Is ASN, Anyway? covers the basics.
Check It Yourself
The fastest way to calibrate your expectations is to test with addresses you know. Open What Is My IP and see how your own connection resolves - on home broadband, the city is usually right or one town over; on mobile data or a VPN, you will often see the carrier gateway or exit node instead, which is the estimate working as designed. Then try a full lookup against the API:
curl -X GET "https://api.theipapi.com/v1/ip/8.8.8.8?api_key=YOUR_API_KEY"
The response includes the location estimate alongside the ASN, company, and is_vpn / is_datacenter / is_bogon flags, so you can see in one call both the estimate and the context that tells you how much to trust it. Field-by-field details are in the documentation, and the FAQ covers the most common accuracy questions we get.
So, How Accurate Is IP Geolocation?
IP geolocation is highly accurate at the country level because it is built on the RIRs' own allocation records. Below that, it is an inference that dynamic assignment, coarse WHOIS data, CGNAT, and VPNs all blur - with RFC 8805 geofeeds steadily improving the picture where operators publish them. Coordinates are representative points for an area, never a street address. Build with those boundaries in mind and the data is genuinely useful; ignore them and you end up sending people to a farm in Kansas.
Want to see how your own traffic resolves? Sign up for The IP API - the free tier includes 1,000 requests per day, no credit card required.
