How accurate is IP geolocation? Country vs city, and what to use it for

"How accurate is IP geolocation?" doesn't have one number for an answer, and anyone who gives you one without a methodology is guessing. What we can say with confidence is why it is accurate in some situations and wrong in others. That's what you need to decide what to build on it.

The short version: country-level results are usually reliable; city-level results are an approximation; coordinates are a point inside an area, not an address.

Where IP location data comes from

An IP address has no built-in location. Geolocation databases infer one from several kinds of evidence:

Registry records. Regional internet registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) record which organization holds an address block and its country. That's a strong country signal but a weak city signal: a national ISP registers all its blocks at its head office.
Geofeeds published by networks. Operators can publish where their address ranges are used, in a simple CSV format standardised as RFC 8805. RFC 9632 describes how to find these feeds from registry records. Where a network publishes one, it's usually the best data available, because it comes from the operator.
Network measurements. Latency from known vantage points, router hostnames that contain city codes (fra, ams, nyc), and routing data narrow down where an address is reached.
Corrections and user-submitted data, which providers collect in different ways.

Every provider weighs these differently, which is why two services can disagree about the same address.

Why the country is usually right

Most address blocks are registered, routed and used in one country. The registry, the routing and the operator's geofeed tend to agree. The common exceptions:

VPNs and proxies show the location of the exit server, by design.
Privacy relays. Services like iCloud Private Relay route traffic through egress nodes. Apple publishes its egress ranges mapped to an approximate region, so the user's country (and sometimes region) is preserved but not their city.
Corporate networks may send all employee traffic out through one country.
Satellite and some mobile networks can route users through gateways in a neighbouring country.
Recently moved blocks. When addresses are sold or reassigned, databases take time to catch up.

Why the city is only approximate

At city level the evidence is thinner and the network design works against you:

Mobile carriers route large regions through a few gateways. A phone in one city can appear to be in another one far away.
Carrier-grade NAT (CGNAT) puts many customers behind shared addresses.
ISPs reassign addresses dynamically between regions.
Registry addresses point at head offices, not customers.

That's why the latitude and longitude in a response should be read as "a point somewhere in the estimated area". Showing a precise map pin implies accuracy the data doesn't have.

What IP geolocation is good for

Good fits (country or region, with a fallback):

Default currency, language suggestion and country dropdowns.
Regional compliance notices and cookie banners.
Analytics by country.
Fraud signals, such as an IP country that doesn't match the billing country, used as one input.
Time zone defaults (the timezone field).

Poor fits:

Anything that needs a street address or a precise distance.
Hard legal enforcement without another check. VPNs defeat it, so treat it as a best effort.
Identifying a specific person. An IP identifies a connection, often a shared one, not an individual.

Design around the uncertainty

Always let users override. A location picker beats a wrong guess every time.
Prefer user-provided data when you have it. A billing address or a GPS fix from the browser (with permission) beats IP geolocation.
Degrade gracefully. Treat a missing field or a failed lookup as "unknown", not as an error. See the error handling notes.
Use the right granularity. Use country_code for logic. Use city for "you might be near…" copy, never for decisions.
Combine with network data. asn and organization tell you if the address is a cloud provider, where the location is the data centre's, not a person's. See ASN lookup by IP.

How to measure it for your own traffic

If accuracy matters to you, measure it on your own audience rather than trusting anyone's headline number, ours included:

python

# Compare IP country with the billing country customers gave you (with consent).
import collections

def accuracy_report(rows):
    """rows: iterable of (ip_country_code, billing_country_code)"""
    total, match = 0, 0
    mismatches = collections.Counter()
    for ip_cc, bill_cc in rows:
        if not ip_cc or not bill_cc:
            continue
        total += 1
        if ip_cc == bill_cc:
            match += 1
        else:
            mismatches[(bill_cc, ip_cc)] += 1
    print(f"country agreement: {match}/{total} = {match / max(total, 1):.1%}")
    for (bill, ip), n in mismatches.most_common(10):
        print(f"  billing {bill} but IP says {ip}: {n}")

Disagreement doesn't always mean the geolocation is wrong: travellers, VPN users and cross-border shoppers are real. The mismatch list usually shows clear patterns, such as one neighbouring country or one mobile network.

Privacy: location data is personal data

Accuracy isn't the only design question. In the EU, the Court of Justice held in Breyer (case C-582/14, 2016) that even a dynamic IP address can be personal data for a website operator under certain conditions. Location derived from it should be handled with the same care:

Store the least you need. Keep country_code for analytics. You rarely need the raw IP or the coordinates for long.
Truncate or hash IPs in logs that you keep for statistics.
Mention geolocation in your privacy notice if you use it for personalisation or fraud checks.
Don't build profiles from city-level guesses. They are inaccurate and sensitive.

This isn't legal advice. Check the rules that apply to your service.

How IPAPI.GR approaches it

IPAPI.GR combines several geolocation data sources for each uncached lookup, rather than relying on a single database. Results are cached, and the timestamp field tells you when the data was looked up. With &dev you can see cache status and, for uncached responses, which datasheets answered. The details are in the docs. We don't publish an accuracy percentage, because we have no independent ground-truth dataset to back one up.

What we can state precisely are the risk flags on Pro. They aren't estimates. They're set only when an address is in a bot operator's published ranges or passes forward-confirmed reverse DNS. See verifying AI crawler IPs.

FAQ

Why does a lookup show a different city from where I am?

Most likely your ISP or mobile carrier routes your traffic through another city, or the database has the block registered at the ISP's head office. A VPN or relay has the same effect.

Why do two providers give different answers?

They use different sources and weigh them differently. When one of them uses an operator's geofeed and the other uses registry data, the geofeed answer is usually the better one.

Can I correct a wrong location for my network?

If you operate the network, publish an RFC 8805 geofeed and reference it from your registry records as RFC 9632 describes. Many geolocation providers read them.

Start building: get a visitor's country from their IP address.

Tagged IP geolocation Guides