Last updated: September 26, 2026 · 11 min read

The test

Most articles about IP geolocation accuracy quote a vendor's own marketing figure. We wanted numbers we could check, so we ran a small experiment on 26 September 2026 and published the raw output alongside this page.

We picked 15 IPv4 addresses: two well-known anycast resolvers (8.8.8.8 and 1.1.1.1) and 13 ordinary unicast addresses belonging to universities and national research networks across 13 countries. Research-network addresses are deliberately boring targets — they are stable, publicly documented and sit in cleanly delegated blocks. We then asked three free, no-key geolocation APIs where each address was, recorded the city, region, country and coordinates each one returned, and computed the great-circle distance between every pair of answers. The largest of those distances is what we call the spread.

The results

City names are reproduced exactly as each API returned them, including the odd sub-district labels. Spread is the maximum great-circle distance between any two of the three coordinate pairs. Full raw responses, including the pairwise distances, are in the test output file described in the methodology below.

What the numbers say

The pattern is consistent and, once you see it, fairly intuitive: the coarser the question, the better IP geolocation does.

• Country: 15/15. Every provider agreed on the country code for every address, including the two anycast resolvers. Not one disagreement.
• Region: 5/15 returned byte-identical region strings — though much of that gap is naming rather than geography (“Zurich” vs “Kanton Zurich”, “Madrid” vs “Comunidad de Madrid”).
• Exact city name: 3/15. Only 128.232.0.20, 150.203.1.1 and 130.206.1.1 produced three identical city strings.
• Within 25 km of each other: 10/15 — a better measure than string matching, since it forgives “Braunschweig” vs “Brunswick”. 9 of 15 landed within 10 km.
• More than 100 km apart: 4/15. Those were 8.8.8.8, 1.1.1.1, 202.120.224.1, 193.204.114.1.
• Median spread: 9.1 km. The median is the honest headline — the mean is dragged to 420 km by a single outlier.

Strip out the two anycast addresses and the 13 ordinary unicast ones have a median spread of 8.6 km, with a worst case of 1,080 km (202.120.224.1). So for a normal, well-documented address, the providers usually land in the same metropolitan area — and occasionally in a different part of the country entirely.

Why they disagree

Every disagreement in our data falls into one of four mechanisms. None of them is a bug.

1. Anycast: the address is genuinely in many places at once

Our worst result by a wide margin was 8.8.8.8, Google Public DNS, at 3,859 km. One provider placed it in Ashburn, Virginia; another in Mountain View and the third in San Jose, both in California — opposite sides of the United States.

Here is the thing: none of those answers is wrong. Anycast means the same address is announced simultaneously from dozens of data centres worldwide, and your packets reach whichever one is nearest to you. Asking “where is 8.8.8.8?” is like asking which branch a bank's phone number is in. The databases are each reporting a different real location, or the corporate registration address, and the question itself has no single answer.

1.1.1.1 shows the same effect more subtly. All three providers agreed on Australia, but placed it in South Brisbane, Sydney and Brisbane — a spread of 733 km between Queensland and New South Wales, from a service that answers in practically every major city on earth.

2. Registry location, not physical location

An IP address block has a registered holder, and that registration carries an administrative address. That address is frequently the organisation's head office, not the building the equipment lives in — and a database with nothing better to go on will use it.

This produced our worst unicast result. 202.120.224.1 belongs to a Chinese university network (AS4538 China Education and Research Network Center). Two providers placed it in Shanghai; the third put it in Haidian (Haidian Qu), Beijing — 1,080 km away, and the district that hosts the network's national administration. 193.204.114.1, on the Italian research network AS137 Consortium GARR, split the same way: Rome from two providers, Turin from the third, 525 km apart.

If a national organisation holds one big allocation, the registry says where the organisation is. It does not say where each individual address is used.

3. Your ISP's network, not your building

Where a database has real network intelligence rather than just registry data, it often reflects the point where an ISP aggregates or routes traffic — which can be a different town from the end user.

132.229.0.1 (Leiden University, via AS1103 SURF B.V.) is the clearest case: two providers said Leiden, one said Amsterdam — 36.7 km away, and the obvious hub for a Dutch national network. Two smaller examples work the same way: 129.132.1.1 came back as Zurich twice and Effretikon once (12.2 km, a satellite town), and 129.241.1.1 as Trondheim twice and Kattem once (10.0 km, a suburb of the same city).

This is exactly the mechanism that puts a home broadband user in their ISP's regional hub rather than their own town — and it is why the wrong-city complaint is so common.

4. Granularity and naming, which only look like errors

Some disagreements are not geographic at all. 134.169.1.1 returned Braunschweig from two providers and Brunswick from the third — the English exonym for the same German city, 1.8 km apart in coordinates. 18.9.22.169 came back as Cambridge, Cambridge (Area 2/MIT) and Boston — three labels for points 3.3 km apart across a river. Others answered with sub-districts: Singapore (Queenstown Estate) and Chiyoda City are more precise than the city names their rivals returned, not less.

This is precisely why we measured distance instead of comparing strings. String equality would have scored these as failures; 1.8 km is not a failure.

What this means in practice

If a website says it knows which country you are in, believe it — that was perfect across our sample, and it is why region-locked streaming and country-level fraud rules lean on IP data so heavily. If it claims to know your city, treat that as a guess with a plausible error of a few kilometres and a real chance of being in the wrong region altogether. And if it implies it knows your street, it is bluffing: nothing in an IP address encodes that, and our best-documented addresses still moved by kilometres between providers.

You can reproduce the disagreement yourself in about a minute. Run the same address through our bulk IP lookup tool, then through any other lookup service, and compare the cities. To see what your own connection reports, start with what is my IP address. And if the answer you get is one you would rather other sites did not see, using a VPN replaces it with the address of the VPN server — which, as our anycast results show, is a location the databases will then disagree about on your behalf.

Methodology

Run on 26 September 2026, from a single vantage point in the United Kingdom. 15 IPv4 addresses (two anycast, 13 unicast across 13 countries). We attempted four free no-key APIs and three answered:

• ip-api.com — answered 15/15
• freeipapi.com — answered 15/15
• ipwho.is — answered 15/15
• ipapi.co — answered 0/15. Every request was refused with RateLimited from this network, so it is excluded from all figures above. Its refusals are retained in the raw output.

Distances are great-circle (haversine, Earth radius 6,371.0088 km) between each provider's reported latitude and longitude. For each address we computed all three pairwise distances and report the maximum. Requests were paced at roughly one every 1.5 seconds. The complete raw JSON — every response, every pairwise distance — was written to _geo-test.json, and every figure on this page is computed from that file.

Limitations

Three matter, and they all point the same way. First, as noted above, provider disagreement is a lower bound on error, not a measure of accuracy. Second, 13 of our 15 addresses belong to universities and national research networks — among the best-documented address space on the internet. Ordinary residential, mobile and carrier-grade NAT addresses are harder to place, so these results are close to a best case, and consumer IPs will do worse. Third, this is one sample at one moment from one network; geolocation databases are updated continuously, and the same query next month may return different cities.

Frequently Asked Questions

How accurate is IP geolocation, really?

At country level, extremely: all three providers agreed on the country for all 15 of our addresses. At city level, much less so — only 3 of 15 addresses produced the same city name from all three, and 10 of 15 landed within 25 km of each other. Since this sample is weighted towards unusually well-documented addresses, treat the city figure as optimistic.

Why do two IP lookup sites show me different cities?

Because they are different databases built from different evidence, and neither is reading your device. In our test, 12 of 15 addresses produced at least two different city names. Most of those gaps were a few kilometres — an ISP hub instead of your town, or a sub-district instead of the city — but four exceeded 100 km.

Does a disagreement mean one of them is wrong?

Yes, at least one must be, and you can bound it: if two providers are 1,080 km apart, one of them is off by at least half that. But the reverse does not hold. When all three agree, they may simply be repeating the same registry record, and our test cannot tell the difference.

Why is 8.8.8.8 reported in completely different cities?

Because it is anycast: the same address is announced from many data centres at once, so there is no single correct answer. It gave us our widest spread, 3,859 km. Any large public DNS resolver, CDN edge address or VPN gateway can behave this way.

Can my IP address reveal my home address?

No. The finest distinction in our data was a few kilometres, on addresses far better documented than a home connection, and the mechanisms above all resolve to network infrastructure rather than premises. An IP address can be linked to a subscriber, but only by the ISP that issued it, and normally only under a legal request.

Will a VPN change what these databases report?

Yes — sites will see the VPN server's address and look that up instead, which is the point. Whether the reported city is right for the server is a separate question, and as our anycast results suggest, large VPN providers announcing addresses from many locations are exactly the case these databases handle worst. Our guide to VPNs and what they hide covers the trade-offs.