A fraud team sees a login "from another country", a content provider blocks a user who is at home, a log dashboard plots attacks on a map. All three depend on IP geolocation, and all three can be wrong. Knowing how the location is estimated is what separates a useful hint from a false conclusion.
IP Geolocation shows the approximate location of any public IPv4 or IPv6 address on a world map, together with the registry owner, the routing network and reverse DNS, so the location can be judged in context instead of on its own.
What is IP geolocation?
In simple terms
IP addresses are not tied to places. Geolocation databases build a best guess by combining which provider holds a block, where that provider says it uses it, network measurements and other signals, and then publish "this range is probably in this city". A lookup finds the range containing your address and returns that guess.
Technical background
Commercial and free databases (such as DB-IP, used here) map IP ranges to a country, region, city and a representative latitude and longitude. They are typically distributed in the MaxMind DB (MMDB) binary format: a search tree keyed by address bits with a data record per network. Inputs include registry data, operator-published geofeeds (RFC 8805), latency measurements and feedback.
Several properties of the internet limit accuracy:
- Aggregation. Providers assign addresses from regional pools; a city-sized pool often maps to the city of the hub.
- Tunnels and gateways. VPNs, corporate proxies, privacy relays and mobile carriers route traffic through central gateways; the database sees the gateway.
- Anycast. One address is announced from many sites (RFC 4786); any single location is only one of them.
- Re-assignment. Address blocks are transferred, leased and moved between regions faster than databases update.
- Coordinates are representative. A city-level result places a pin at a point representing the city or region, not a measured position.
Why use IP Geolocation?
- Sanity-check "impossible travel" alerts. Before treating a login as suspicious, see whether the address belongs to a VPN, mobile carrier or cloud provider whose location is inherently fuzzy.
- Debug geo-restricted content. See where a database places an address that a service blocked or redirected.
- Plan or verify CDN and anycast behavior. Confirm that an address belongs to an anycast network rather than a single site.
- Add context to log analysis. Combine approximate location with owner and ASN instead of relying on the map alone.
Who should use it?
- Security analysts and fraud teams assessing login and transaction alerts.
- Network operators checking how their own ranges are geolocated.
- Support staff handling "the site thinks I'm in another country" reports.
- Developers testing geo-dependent features.
How IP Geolocation works
The address is validated in the browser; private, reserved and other special-use addresses are refused with an explanation, because they have no meaningful location. Public addresses are sent to the NetTools.tech API, which produces the same combined report as IP Lookup:
- Location. The server looks up the address in a local copy of the DB-IP "IP to City Lite" database (CC BY 4.0), imported monthly. It returns city, region (first subdivision), country, country code, continent and coordinates rounded to four decimal places, together with the database name and build date. If the database has no entry, the location card says so. No geolocation request is sent to any third party.
- Registry. The holder, range and registration country from the RDAP record of the responsible regional registry, found through the IANA bootstrap registry.
- Routing. Origin ASN, announced prefix and routing-data country from Team Cymru's IP-to-ASN DNS service, queried through 1.1.1.1 and 8.8.8.8.
- Reverse DNS. The PTR hostname, if any.
The browser places the coordinates on a world map. If the origin ASN belongs to a network known for anycast or CDN services (including Cloudflare, Google, Quad9, PCH, Fastly, Akamai, Cisco OpenDNS and Imperva), the page adds an anycast warning. If the registry and routing data disagree on the country, both are shown. Every location result carries the DB-IP attribution and the database date.
How to use the NetTools.tech IP Geolocation
- Open IP Geolocation.
- Type an address into the IP address field (for example
8.8.8.8) and press Look up, or press Use my IP, or click an example chip. - Look at the Location card: the map pin, the approximate location line, coordinates and continent.
- Read the notes under the map: the anycast warning, the reminder that the location describes the provider's address block, and the data source with its date.
- Compare with Registration country, the Network owner card and Routing (BGP) before drawing conclusions.
- Share a result with the URL, which includes
?ip=…, or copy the coordinates with the Copy button.
Understanding the results
| Result | Meaning | What to look for |
|---|---|---|
| Map pin | Coordinates from the database, plotted on a world map | A representative point, not a measured position |
| Approximate location | City, region and country, as far as the database knows them | Missing city means the database only knows region or country |
| Coordinates | Latitude and longitude, four decimals | Precision of the digits is not accuracy of the location |
| Continent | Continent from the database | Useful for coarse routing or latency expectations |
| Registration country | Country in the registry record (or routing data if the registry has none) | Where the block is registered, not where it is used |
| Routing data country | Shown only if it differs from the registration country | Indicates internationally used or leased space |
| Anycast note | The origin network is a known anycast/CDN operator | Treat the city as one of many serving locations |
| Source line | "IP Geolocation by DB-IP", database name and build date, CC BY 4.0 | Old data explains recently moved ranges |
| Network owner / Routing (BGP) | Holder and announcing network | VPN, hosting and mobile networks make location less reliable |
Example: an "impossible travel" alert
A user logs in from Riga, and ten minutes later from an address the alerting system places in Amsterdam. The second lookup (illustrative, using documentation values) returns:
198.51.100.140 IPv4
Location: Amsterdam, North Holland, Netherlands (approximate)
52.3740, 4.8897 · Europe
Registration country: Netherlands (NL)
Network owner: Example Mobile Operator B.V.
Routing (BGP): AS64502 · Example Mobile Operator
Source: IP Geolocation by DB-IP · DB-IP IP to City Lite, CC BY 4.0The owner is a mobile operator. Mobile traffic often leaves through a central gateway, so this pattern is consistent with the user switching from office Wi-Fi to mobile data, not with travel. Combined with device and session data, the alert can probably be closed; on its own, the location proves nothing either way.
Common use cases
- Triage of geo-based security alerts before escalating.
- Checking how a newly acquired or moved IP range is currently geolocated.
- Understanding why a streaming or banking service treats a connection as foreign.
- Identifying anycast addresses for DNS resolvers and CDNs.
- Adding approximate region context to abuse reports.
Troubleshooting
The location card says not available
The database has no entry with coordinates for the address, or the database has not been imported on the server. The registry and routing cards are still shown.
The city is the provider's headquarters
Many providers register whole regional pools at their main site. The country is usually still right; the city is not meaningful.
A well-known DNS resolver shows a single city
Addresses such as 1.1.1.1 or 8.8.8.8 are anycast. You reach the nearest site; the database shows one representative location. The page adds an anycast note for these networks.
My own range is placed in the wrong country
Check the registry country and whether the block was recently transferred. Publish a geofeed and submit a correction to the database provider; the change reaches NetTools after it appears in a monthly DB-IP Lite release.
Common mistakes
- Treating coordinates with four decimals as a precise position.
- Using geolocation as proof of where a person was.
- Confusing registration country with location.
- Ignoring the owner: VPN, hosting and mobile networks are inherently imprecise.
- Basing access decisions solely on city-level data.
Limitations
- DB-IP Lite is a free, city-level database refreshed monthly; it is less detailed than commercial editions and can lag behind changes.
- Locations describe the provider's address block, never a device, household or person.
- Anycast detection relies on a fixed list of known anycast networks; others are not flagged.
- VPN and proxy use is not detected as such; you have to infer it from the owner and ASN.
- The map shows one point; it does not draw an accuracy radius.
Security & privacy
The address you enter goes to the NetTools server. Location is looked up in a database stored on the server, so no geolocation provider sees your query; registry and routing lookups go to IANA-listed RDAP servers and public DNS resolvers, which see the NetTools server rather than you. The tool log keeps the tool name, target and your shortened IP for 30 days (privacy policy); results are not stored. Do not use IP geolocation to try to locate private individuals: it cannot do that, and attempting it can be harmful.
Related tools
- IP Lookup – the full ownership and routing report. Guide: IP Lookup guide.
- My IP – the location the database gives your own connection. Guide: What is my IP.
- ASN Lookup – the network that announces the address. Guide: ASN Lookup guide.
- Traceroute – the actual network path, often more telling than a database. Guide: Traceroute guide.
- Ping – latency from the NetTools server as a rough distance check. Guide: Ping guide.
- Overview: IP & Network Utilities.
Summary
IP Geolocation places an address on a map using the DB-IP City Lite database stored on the NetTools server, and shows the registry owner, BGP routing and reverse DNS alongside it. Expect country-level results to be mostly right and city-level results to be approximate at best, especially for mobile, VPN, cloud and anycast networks. Use it as context for decisions, never as proof of where someone is.
Frequently asked questions
How accurate is IP geolocation?
It is usually right at country level, often right at region level and frequently wrong at city level. Mobile networks, VPNs, corporate proxies, cloud providers and anycast services are the most common sources of error, and no database can resolve an IP address to a street address.
Where does the NetTools location data come from?
From a local copy of the DB-IP IP to City Lite database, licensed CC BY 4.0, which the server imports monthly. The source and the database build date are shown with every result, and no lookup is sent to a third party.
Why does my IP show a city I am not in?
Geolocation databases describe where a provider's address block is used, which is often the city of a network hub, data center or the provider's headquarters. With a VPN or mobile data, the location is that of the provider's gateway, which can be hundreds of kilometers away.
What does the anycast note mean?
Some networks announce the same address from many locations worldwide, so users reach the nearest site. For addresses routed by networks the tool knows to use anycast, the page warns that the single city shown is only one of many places the address is served from.
What is the difference between registration country and location?
Registration country is the country recorded in the regional registry for the address block. Location is a geolocation database estimate of where the block is used. They often differ for international networks, and neither proves where a device is.
Can I correct a wrong location for my own IP range?
The NetTools page only displays the database result and cannot change it. Network operators can publish a geofeed (RFC 8805) and submit corrections to geolocation database providers, and the change appears after the next monthly import.