IP Geolocation Accuracy: City vs Country vs ISP Level

Every IP geolocation provider’s marketing page makes the same claim in slightly different language: “highly accurate location data, down to the city.” That sounds impressive until you realize city means very different things to different providers — and that the accuracy of any of them varies wildly by region, address type, and how recently the data was updated.

This post is an honest look at what “accuracy” actually means in IP geolocation, why country-level data is reliable but city-level data is often a confident guess, and how to use each level without overreaching.

The Three Levels (and What They Really Mean)

IP geolocation databases generally cover three resolution levels:

Country-level

The country the IP is registered in (technically, the country associated with the RIR allocation). This is the most reliable layer — usually 99%+ accurate for residential and business IPs in stable markets.

Country-level data is what regulators care about for geofencing, what most personalization needs, and what virtually every API includes for free or close to it.

City-level

The city (or metropolitan area) the IP is most likely in. This is where it gets fuzzy. City-level accuracy in major markets is typically 70–85% for residential IPs, but drops to 30–50% for mobile-network IPs and corporate IPs.

When a provider says “city-level accuracy of 90%,” they typically mean: for IPs that we have specific city data for, in the markets we’ve benchmarked, accuracy is ~90%. For IPs they don’t have specific data for, they fall back to the country’s largest city or some sort of centroid, which inflates apparent coverage without inflating real accuracy.

Coordinates

Latitude and longitude. This sounds the most precise but is actually the most misleading. The lat/long returned by an IP geolocation API is not the user’s location — it’s a representative point for the IP’s geographic estimate. Often it’s the centroid of the country’s largest city, or a postal code, or a known network hub.

If you plot IP-derived coordinates on a map, you’ll see clusters of identical points (everyone in Berlin gets the same lat/long) and offsets of 5–50km from actual user locations. This is normal. Don’t treat the coordinates as ground truth.

Why Accuracy Varies

A few structural reasons:

Data sources are not perfect

Geolocation databases blend several sources: RIR allocations (country-level, accurate), BGP routing (network-level, accurate), active probing (best-effort triangulation), public data (Wi-Fi positioning where available), and user-submitted corrections.

Each source has different accuracy and different coverage. A residential IP from a major US ISP might have very precise data because the ISP publishes street-level information. The same provider’s residential IP in a smaller country might only have country-level data because no such public info exists.

IPs move

Network operators renumber. Cellular providers grow into new markets. A range that was Berlin last year might be Vienna this year. Geolocation databases need constant updating — and self-hosted databases inevitably lag.

Cellular networks are inherently fuzzy

Mobile carriers route traffic through gateways that can be hundreds of miles from the actual user. CGNAT (carrier-grade NAT) makes it worse — thousands of users share one public IP, with that IP’s location being the carrier’s gateway, not any user’s.

If a meaningful share of your traffic is mobile, expect city-level data to be wrong much more often than residential traffic suggests.

VPNs, proxies, and privacy services

Apple Private Relay, Cloudflare Warp, commercial VPNs — these all route user traffic through an exit IP that’s not where the user is. The geolocation of an IP behind one of these services is correct for the exit, not the user.

Anycast addresses

Some IPs are anycast — the same IP routes to different physical locations depending on the requester. DNS resolvers (1.1.1.1, 8.8.8.8) work this way. There’s no single “where is this IP” answer for these. Geolocation databases handle them inconsistently.

How Providers Compare

Real-world accuracy varies between providers, and even within the same provider varies by region. A few patterns from public benchmarks:

• Free databases (GeoLite2) lag the commercial products meaningfully — city-level accuracy in the 60–70% range, country-level in the 95% range.
• Commercial offline databases (MaxMind GeoIP2, IPinfo’s offline product) sit at 80–90% city-level, 99%+ country-level.
• Hosted APIs with continuously refreshed data tend to be in the same band as commercial offline databases, but with better freshness — newly allocated IPs are mapped within days rather than waiting for the next download cycle.

The big variation is by region. North American and Western European IPs are the most well-mapped because the data sources are richest there. African, Latin American, and parts of Southeast Asian IPs are less well-mapped — partly less infrastructure for active probing, partly less public data from ISPs.

If your user base is concentrated in a specific region, benchmark against that region, not against global averages. Marketing pages quote global numbers, which can hide significant gaps in your specific market.

What to Use Each Level For

Use country-level for:

• Compliance and geofencing. Geofencing decisions are typically per-country anyway.
• Default currency and language. Personalization defaults are country-driven; the user can override if you got it wrong.
• Fraud signals. Country mismatches between IP, billing, and card BIN are useful, well-understood signals. See fraud detection.
• Routing decisions. Picking the right regional endpoint or CDN POP.
• Analytics segmentation. Country-level breakdowns are reliable enough for product analytics.

Country-level data is reliable enough to make actual decisions on.

Use city-level cautiously for:

• “Local store” features. Showing nearby physical stores or services. Acceptable when there’s also a fallback (manual location entry) and the user understands the result might be approximate.
• Marketing personalization. “Used by teams in [your city]” can land well, but only when the data is actually right. If you get it wrong even 20% of the time, the misses are jarring.
• Time zone defaults. City often gives you a more specific timezone than country alone, useful for scheduling features.
• Analytics granularity. When you want to know where your users are concentrated within a country, city-level rollups give a directional answer — but don’t bank on individual data points.

City-level data is good enough for soft defaults, not for hard decisions.

Don’t use coordinates for:

• Anything precise. Coordinates from IP geolocation are not pin-drops. Distance calculations from IP coordinates have error in the tens of kilometers.
• Map markers. Showing a marker on a map “here’s where you are” based on IP coordinates is misleading. The marker is the database’s representative point for the IP, not the user.
• Delivery/pickup logistics. Use the user’s declared address. IP coordinates are wrong too often to plan around.

If you need actual precise coordinates, use the browser’s Geolocation API (GPS-based, with user permission) — not IP-derived data.

Practical Tips for Using Geolocation Data Honestly

1. Confidence is real signal

Some providers (including better commercial ones) return a confidence or accuracy_radius field with each lookup. Use it. If the confidence radius is 100km, don’t show the user a city name as if it’s precise.

2. Fall back gracefully on unknowns

A meaningful percentage of IPs will not have city-level data, especially in less-covered regions. Your code should treat “unknown city” as a valid state and not display empty or placeholder data.

3. Cache the lookups

The geolocation of an IP doesn’t change in a 10-minute window. Cache at the edge to reduce API calls and latency.

4. Let the user correct it

If you’re using geo data to drive UI defaults, give the user a visible way to change it. The 2% who are wrongly detected will appreciate this enormously.

5. Don’t claim precision you don’t have

Your marketing copy that says “we know where you are!” sets up disappointment. “We default to your country, you can change it” is honest and lands well.

6. Test the edge cases

A handful of IPs every IP-geo team should test against:

• 1.1.1.1 — Cloudflare anycast, no meaningful city
• 8.8.8.8 — Google anycast, no meaningful city
• A known Tor exit node
• A known commercial VPN exit
• A mobile carrier IP from each region you care about
• A satellite ISP (Starlink) IP
• An IP from a small or less-covered country

If your code handles these without breaking, it’ll handle production.

What “Better Accuracy” Actually Means in 2026

A few realistic trends from where the industry is in 2026:

• Country-level data is essentially solved. All major providers are in the high 90s.
• City-level is converging. The gap between best-in-class and median is narrowing as data sources improve, but it’ll never be perfect.
• Mobile remains hard. As more traffic moves to mobile, the average accuracy of “any random user’s IP geo” actually trends down even as providers improve.
• Privacy services keep growing. Apple Private Relay, Warp, and similar services obscure the user’s real IP from your perspective. Your geolocation will be of the proxy, not the user — and there’s no way around that within IP geolocation alone.
• Fresh data matters more than fancy algorithms. A hosted API updated daily is more accurate in practice than a commercial offline database updated weekly, simply because IP allocations move.

When the Accuracy Limit Matters

For most uses — currency defaults, country-level analytics, fraud signals — IP geo accuracy in 2026 is more than good enough. Country-level reliability of 99% means 1 in 100 users sees the wrong default, and they fix it via an override.

The accuracy limit starts to matter when:

• You’re using city-level data for a hard decision (regulatory boundary, distance-based pricing).
• You’re using coordinates for anything more than rough analytics.
• You’re operating in a less-covered region where the data is genuinely thin.
• You’re routing real-time decisions on inaccurate data (e.g., precise delivery estimates from IP coordinates).

In all these cases, the right answer is to combine IP geo with other signals — declared address, GPS, payment-method country — and use the IP layer as one input, not the source of truth.

TL;DR

• Country-level: very accurate (~99%). Use it freely.
• City-level: roughly 70–85% in well-mapped regions, much less in others. Soft defaults only.
• Coordinates: representative points, not user positions. Don’t treat as ground truth.
• Mobile and VPN traffic degrade accuracy. Plan for it.
• Fresh data > algorithmic sophistication. A 1-week-stale database is worse than a daily-updated API.
• Let users override. Auto-detection is a hint, not a sentence.

If you’re picking a provider and accuracy is the question, the practical advice is: don’t trust marketing-page accuracy numbers. Test against your real traffic. Most teams find that a hosted API like Ip2Geo (continuously updated, edge-deployed) gives better real-world accuracy than offline databases because the data is fresher, not because the underlying algorithms are dramatically different.

The honest summary: country-level IP geolocation is a solved problem. City-level is acceptable for soft defaults. Coordinates are for analytics, not user-facing precision. Build your product within those limits and the geo layer disappears into the background — exactly where it belongs.