Where IP geolocation is accurate and where not

Addresses are handed out in layers. IANA allocates blocks of IPv4 space to the five regional internet registries: APNIC, ARIN, RIPE NCC, AFRINIC and LACNIC ¹. A registry then delegates ranges to network operators, who split them among customers. The registry record tells you which organization holds a range and usually a country of registration. It says nothing about a street.

A geolocation database starts from that ownership data and adds its own estimates for finer places. The publisher of the database we use states the limit plainly: its free Lite edition is a subset of the full database with reduced coverage and accuracy ². Neither it nor the page we read publishes an accuracy percentage, so we do not quote one. Treat every city as an estimate with no stated error bar.

Carrier-grade NAT lets several subscribers share one public IPv4 address. The RFC that reserved 100.64.0.0/10 for it lists, among the side effects, that geolocation systems may identify the NAT server rather than the end host ³. The same effect applies to any gateway that fronts many users.

Routing adds one more twist. An address block can move between operators, and a range can be announced from a different place than where its users are. A database built on a monthly snapshot will lag behind such changes, which is one more reason to read old results with care.

The product reads two open datasets from DB-IP: the City Lite database for place and the ASN Lite database for the network owner. Both are licensed CC BY 4.0, and the publisher requires credit to DB-IP, with a link back from web pages that display the results ². Every response carries an attribution field with the credit text, and your pages that show the data should repeat it.

• country: ISO 3166-1 alpha-2 code. The steadiest field.
• region, city, latitude, longitude: the database's estimate. timezone is always null because the Lite source has no time zone field.
• asn and asn_org: the autonomous system number and the organization that holds it.
• is_hosting and hosting_provider: true when the address falls inside a cloud or hosting provider's published ranges.
• is_tor: true when the address is on the Tor Project exit list. is_vpn is always null, meaning unknown, never false.

Private, loopback, documentation and carrier-grade NAT ranges are not public addresses, so the product answers with an invalid-input error for them instead of inventing a place. A public address that no dataset covers returns not found.

1curl -X POST https://YOUR_API_HOST/v1/ip \
2  -H "Authorization: Bearer $LOOKVALID_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{"ip":"8.8.8.8"}'

1{
2  "ip": "8.8.8.8",
3  "country": "US",
4  "city": "Mountain View",
5  "timezone": null,
6  "asn": 15169,
7  "asn_org": "Google LLC",
8  "is_hosting": true,
9  "hosting_provider": "Google",
10  "is_vpn": null
11}

That address belongs to a hosting provider, so the city names a data center area. It is a good illustration of why is_hosting belongs next to the place whenever you read one.

• Use country for coarse decisions such as default language or a currency suggestion, and let the visitor change it.
• Show city only as a soft label such as "near Mountain View", never as a fact about the person.
• When is_hosting or is_tor is true, or the asn_org is a known carrier, expect the place to describe infrastructure rather than the user.
• Compare against a second signal, for example the billing country or the browser language, before acting on a mismatch.
• Do not ask the database for more than it can give. If a decision needs a real location, ask the person.

To wire the lookup into a server, see check an IP in Express middleware. To try a single address, use the free IP address lookup, and the ip product page lists every field.