The Movie Myth vs. the Engineering Reality
Search for "IP tracker" and the implicit promise is surveillance: follow someone across the internet, watch them move between locations, pinpoint their house on a map. Hollywood has cemented this idea so thoroughly that even technically literate people sometimes overestimate what IP geolocation can do. The reality is both less dramatic and more interesting.
IP geolocation is a statistical inference problem. Given a 32-bit (IPv4) or 128-bit (IPv6) address, the question is: what physical location most likely corresponds to the network infrastructure serving that address right now? The answer comes from combining three independent data sources — BGP routing announcements, active latency measurements, and crowdsourced ground-truth observations — each with its own error profile. No single source is authoritative. The accuracy you get depends on which sources the provider fuses, how recently they updated, and what kind of network the IP belongs to.
Understanding how each pillar works is the difference between treating geolocation as magic (and being wrong) versus treating it as a probabilistic signal (and being useful). Let's take them apart.
The Three Pillars of IP Geolocation
Pillar 1: BGP Routing Data and RIR Registrations
Every IP address block on the public internet is announced via the Border Gateway Protocol (BGP). An Autonomous System (AS) — say, AS7922 for Comcast or AS16509 for Amazon — tells the global routing table: "I can reach 198.51.100.0/24, send traffic for those addresses to me." These announcements propagate across the internet within minutes and are continuously logged by route collectors like RIPE RIS and the University of Oregon's RouteViews project.
Simultaneously, the five Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) maintain records of who was allocated each block. When ARIN assigns 198.51.100.0/24 to Acme Corp with a registered address in Dallas, Texas, that becomes the baseline geolocation for those 256 addresses. The combination of BGP data and RIR records gives you the organization, the ASN, and a rough geographic anchor for every routed prefix on the internet.
The limitation is granularity. RIR registration addresses often reflect corporate headquarters, not the physical location of the network equipment. A company headquartered in San Francisco may operate data centers in Ashburn, Virginia, but the RIR record will point to San Francisco. BGP itself carries no location information — it only describes reachability. So this pillar provides a coarse starting point: you know the organization and their registered address, but the actual equipment could be elsewhere.
Pillar 2: Active Latency Probing
To refine beyond what registrations can tell you, geolocation providers run active measurement campaigns. The principle is straightforward: the speed of light in fiber is roughly 200 km per millisecond. If you send a probe from London and the round-trip time (RTT) is 4 ms, the target is within roughly 400 km. Send probes from London, Paris, Amsterdam, and Frankfurt, and you can triangulate. The intersection of the distance constraints narrows the possible location.
In practice, this is harder than it sounds. Fiber paths are not straight lines — they follow roads, railways, and undersea cable routes. Asymmetric routing means the return path may differ from the outbound path. Congested links add variable queuing delay that has nothing to do with distance. And anycast addresses, where the same IP is simultaneously announced from multiple locations (Cloudflare's 1.1.1.1 is a classic example), break triangulation entirely because different probes reach different physical machines.
Despite these challenges, commercial providers maintain networks of hundreds to thousands of vantage points and run continuous probing campaigns. MaxMind, IP2Location, and ipinfo.io all use variants of this approach. The key insight is that they do not rely on single measurements — they aggregate millions of RTT samples over time and apply constraint-based geolocation algorithms (CBG) that produce a probabilistic estimate with an associated confidence radius. A well-measured IP might have a 10 km confidence radius; a poorly-measured one might have 200 km.
Pillar 3: Ground-Truth Crowdsourced Data
The third pillar is the most accurate and the most controversial. When a mobile app or website obtains GPS coordinates from a device (with user consent), it can pair those coordinates with the device's current IP address. Aggregate millions of these (IP, latitude, longitude) tuples and you get a high-confidence geolocation database that reflects where IPs are actually being used, not where the infrastructure is registered.
This is why geolocation accuracy has improved dramatically over the past decade. The proliferation of smartphones with always-on GPS, combined with ad-tech SDKs and analytics platforms that collect location data (often buried in privacy policies that few people read), has created an enormous corpus of ground-truth mappings. MaxMind, DB-IP, and ipinfo.io all incorporate crowdsourced or partner-contributed location data. Wi-Fi positioning databases, maintained by companies like Apple and Google from the MAC addresses of Wi-Fi access points seen by passing devices, add another layer of corroboration.
The controversy is obvious: this accuracy depends on mass data collection from real users. The ethical providers anonymize and aggregate, discarding individual records after building statistical models. But the line between "anonymized aggregate" and "trackable individual" is not always clear, which is why regulators have taken increasing interest in how geolocation data is sourced.
Accuracy by Network Type
The type of network an IP belongs to is the single biggest predictor of geolocation accuracy. Treating all IPs the same is a common mistake in fraud rules and security policies. Here is what to expect from each category, based on published accuracy studies and MaxMind's own documentation.
Fixed Broadband (~80% City-Level)
Residential ISPs like Comcast, Deutsche Telekom, and BT assign IP addresses from pools allocated to specific metropolitan areas. A Comcast subscriber in Chicago will get an IP from a Chicago-area pool, and geolocation databases reflect this accurately. The confidence radius is typically 20-50 km in well-served urban areas. In rural areas, especially where a single ISP serves a wide region from a distant POP, accuracy drops — a subscriber in rural Montana might geolocate to the nearest city 150 km away.
CGNAT (Carrier-Grade NAT) complicates things even for fixed broadband. Some ISPs share a single public IP among dozens of subscribers. The geolocation still reflects the ISP's pool location, but the IP no longer maps to a single household. This is increasingly common as IPv4 exhaustion forces ISPs to conserve addresses.
Mobile and Cellular (~50-60% City-Level)
Mobile carriers are where geolocation fails most visibly. T-Mobile, Vodafone, and other carriers route mobile traffic through centralized gateways that serve entire regions. A T-Mobile subscriber in Denver might have their traffic exit through a gateway in Dallas. The geolocation database correctly maps the IP to Dallas — that is genuinely where the packets enter the public internet — but the user is 1,300 km away.
The problem is structural. Mobile carriers use massive CGNAT pools (sometimes a single IP represents thousands of concurrent users) and their gateway infrastructure is concentrated in a few locations per country. Even when a carrier operates regional gateways, the geolocation only narrows you to a multi-state region, not a city. If your fraud rules block transactions where IP country differs from billing country, mobile users traveling domestically can trigger false positives because the gateway is in a different state.
Data Centers and Cloud (~90% City-Level)
Cloud and data center IPs are paradoxically the most accurately geolocated and the least useful for identifying real users. AWS, Google Cloud, Azure, Hetzner, and OVH publish their IP ranges, and geolocation databases know exactly which data center each prefix maps to. When an IP lookup says a DigitalOcean IP is in Frankfurt, it is almost certainly in Frankfurt.
But knowing the server location tells you nothing about the person who rented it. An attacker in Lagos running a phishing campaign from a Hetzner server in Helsinki will geolocate to Helsinki. A legitimate SaaS application serving users worldwide from AWS us-east-1 will geolocate to Ashburn, Virginia, regardless of where its customers are. Data center geolocation answers "where is the server?" not "where is the user?"
VPN and Proxy (Shows Exit Node, Not User)
VPN traffic is the hard boundary of IP geolocation. When a user connects to NordVPN's server in Zurich, every service they connect to sees the Zurich IP. The geolocation is technically correct — the IP is in Zurich — but the user could be anywhere on Earth. Commercial VPN providers operate servers in 60-100 countries, and switching between them takes seconds.
Some geolocation providers now offer VPN and proxy detection as a separate signal. They maintain lists of known VPN provider IP ranges, detect behavioral patterns (like hundreds of unrelated users sharing a single IP), and flag these IPs accordingly. The IP Lookup API includes proxy detection flags for this reason. But detection is a cat-and-mouse game: VPN providers rotate IPs, use residential proxy networks, and adopt techniques specifically to evade detection databases.
Satellite Internet (Ground Station, Not User)
Starlink has created a new category of geolocation challenge. Unlike traditional ISPs with geographically fixed infrastructure, Starlink routes traffic through ground stations that may be hundreds of kilometers from the subscriber's dish. A Starlink user in rural Wyoming might have traffic routed through a ground station in Denver or even Seattle, depending on satellite coverage and gateway capacity.
HughesNet and Viasat (legacy satellite providers) have similar issues, though their ground stations are fewer and more predictable. The fundamental problem is that satellite connectivity decouples the user's physical location from where their traffic enters the terrestrial internet. Geolocation databases are gradually learning Starlink's IP ranges and gateway locations, but the accuracy remains at the state or regional level, not city-level.
What IP Tracking Can and Cannot Do
Let's be explicit about the boundaries because the gap between expectation and reality causes real problems — over-blocking legitimate users, false confidence in fraud decisions, and privacy misunderstandings.
What IP Geolocation Can Do
- Identify the approximate city or region for fixed broadband IPs with 55-80% accuracy.
- Determine the ISP, hosting provider, or mobile carrier operating the address.
- Report the time zone associated with the IP's probable location.
- Identify the organization registered as the block owner via RIR records.
- Detect whether an IP belongs to a data center, residential ISP, or mobile carrier.
- Flag known VPN, proxy, and Tor exit node addresses (with some lag).
What IP Geolocation Cannot Do
- Identify the specific person using an IP address at any given time.
- Provide a street address or building-level location.
- Track real-time movement of a device across locations.
- See through VPNs, proxies, or Tor to reveal the user's true location.
- Determine the type of device (phone, laptop, IoT) behind an address.
- Distinguish between multiple users sharing an IP via NAT or CGNAT.
IP Geolocation Databases Compared
Four providers dominate the commercial IP geolocation market. Each makes different trade-offs in accuracy, coverage, update frequency, and pricing. The right choice depends on your region, volume, and accuracy requirements.
MaxMind GeoIP2
The industry standard. MaxMind publishes both a free database (GeoLite2, updated weekly) and commercial databases (GeoIP2 City and Insights, updated multiple times per week). GeoIP2 City claims 80%+ accuracy at the city level for the US, with lower numbers in regions with sparse measurement infrastructure. The Insights product adds confidence scores, connection type detection, and ISP data. MaxMind is the default choice for most applications and has the broadest language and platform support.
IP2Location
A Malaysian company that competes on price and offers both downloadable databases and an API. Their DB25 product includes city, ISP, domain, and proxy detection data. IP2Location tends to perform comparably to MaxMind in Southeast Asia (where their measurement infrastructure is dense) and slightly below in North America and Europe. They offer a one-time purchase model alongside subscriptions, which appeals to organizations that want to avoid recurring costs.
DB-IP
Offers a free tier (DB-IP Lite) and commercial databases with city-level geolocation and ISP data. DB-IP differentiates by including ISP-level data in their free tier, which MaxMind's GeoLite2 does not. Their accuracy is generally in the same range as MaxMind for North America and Europe but they have fewer independent accuracy audits published. Update frequency is twice monthly for free, weekly for commercial.
ipinfo.io
An API-first provider that emphasizes developer experience and real-time data. Unlike MaxMind and IP2Location, which primarily sell downloadable databases, ipinfo.io's core product is a REST API. They claim to process over 600 billion API requests per month and provide ASN, company, carrier, VPN detection, and abuse contact data alongside geolocation. Their privacy detection dataset (identifying VPNs, proxies, Tor, and relay services) is particularly well-regarded. Pricing is per-request with a generous free tier (50,000 requests/month).
Legal and Privacy Considerations
IP geolocation sits at an uncomfortable intersection of utility and privacy. The same data that enables fraud prevention and content licensing also enables surveillance and discrimination. Regulatory frameworks are catching up, and ignoring them creates real legal risk.
GDPR: IP Addresses as Personal Data
The EU's General Data Protection Regulation explicitly classifies IP addresses as personal data (confirmed by the CJEU in Breyer v. Bundesrepublik, Case C-582/14). This means any collection, storage, or processing of IP addresses — including geolocation lookups — requires a lawful basis under Article 6. For most commercial applications, this means either legitimate interest (with a documented balancing test) or consent. You must also honor data subject access requests: if a user asks what IP data you hold about them, you must be able to answer.
In practice, this affects how you log IP-derived geolocation data. Storing raw IPs alongside geolocation results creates a personal data asset that falls under GDPR. Storing only aggregated, anonymized statistics (e.g., "23% of traffic from Germany") does not. Many organizations split the difference: they use IP geolocation in real time for fraud checks but only persist the country code, not the raw IP or city.
CCPA and US State Laws
California's CCPA (and its successor CPRA) classifies IP addresses as personal information and grants consumers the right to know what data businesses collect and to request deletion. Other states — Virginia, Colorado, Connecticut, Utah — have enacted similar laws. The US does not have a federal equivalent to GDPR, but the patchwork of state laws creates compliance complexity for any service that collects IP-based geolocation from US users.
Geo-Blocking and Legal Pushback
IP geolocation is the primary mechanism behind geo-blocking: restricting content or services based on the user's detected location. The EU's Geo-Blocking Regulation (2018/302) prohibits unjustified geo-blocking within the EU for certain categories of goods and services. Streaming services maintain geo-restrictions for licensed content, but regulators have challenged overly broad blocking. In practice, any geo-blocking implementation should use geolocation as one signal among several (combined with billing address, language preference, and user self-declaration) rather than as a sole gating mechanism.
Ethical Use Frameworks
Beyond legal compliance, responsible IP geolocation use means: never treating geolocation as identity verification (it is not), being transparent with users about what location data you collect and why, providing mechanisms for users to correct incorrect geolocation-based decisions, and never using IP geolocation for discriminatory pricing or access decisions without clear justification. If your application blocks a user based on their IP location, they should have a path to appeal that does not require technical sophistication.
Building an IP Geolocation Workflow
For security and fraud teams, IP geolocation is one input into a broader decision engine. Using it well means understanding where it adds signal and where it adds noise. Here is a practical framework for integrating geolocation into production workflows.
Combine Geolocation with Behavioral Signals
IP geolocation alone produces too many false positives for hard blocking. A user on a VPN is not necessarily malicious. A mobile user geolocating to the wrong city is not committing fraud. Instead, combine geolocation with behavioral signals: login velocity, device fingerprinting, session duration patterns, and transaction history. A login from an unusual country plus a new device fingerprint plus a password change request is a strong signal. The unusual country alone is weak.
Use Confidence Scores, Not Binary Decisions
Good geolocation APIs return confidence scores alongside location data. A city-level result with 95% confidence is actionable. The same city with 30% confidence is informational only. Build your rules around thresholds: high-confidence matches pass through, low-confidence results trigger step-up authentication rather than outright blocks. The IP Lookup API includes accuracy radius data that can be used to calibrate these thresholds.
Account for VPN and Proxy Traffic
Between 25-30% of internet users now use VPNs regularly (higher in certain demographics and regions). Blocking all VPN traffic means blocking a quarter of your potential users, many of whom use VPNs for legitimate privacy reasons. Instead, treat VPN detection as a risk modifier: increase the required confidence for other signals when a VPN is detected, but do not block on VPN status alone. Use the domain reputation signals alongside IP data to build a more complete picture.
Handle Geolocation Failures Gracefully
Every geolocation database has gaps. IPv6 coverage is thinner than IPv4. New IP allocations take days to weeks to appear in databases. Satellite internet and emerging mobile carriers may not be covered at all. Your workflow needs a fallback path for when geolocation returns no result or a low-confidence result. The worst outcome is denying service because your geolocation lookup failed — that turns a data gap into a user experience failure.
Geolocation Confidence in Practice
Here is what a well-structured geolocation response looks like when it includes confidence scores. This is the kind of data you should demand from any provider or API you integrate.
{
"ip": "203.0.113.42",
"geolocation": {
"country": "US",
"countryConfidence": 99,
"region": "Illinois",
"regionConfidence": 85,
"city": "Chicago",
"cityConfidence": 72,
"latitude": 41.8781,
"longitude": -87.6298,
"accuracyRadiusKm": 25,
"timezone": "America/Chicago",
"postalCode": "60601",
"postalConfidence": 35
},
"network": {
"asn": 7922,
"asnOrg": "Comcast Cable Communications",
"connectionType": "cable",
"isp": "Comcast"
},
"risk": {
"isVpn": false,
"isProxy": false,
"isTor": false,
"isHosting": false,
"isMobile": false,
"isRelay": false
}
}Notice the gradient of confidence: 99% at the country level, 72% at the city level, and only 35% at the postal code level. This is typical for a residential broadband IP. A fraud rule that checks country-level geolocation can rely on this data. A rule that checks postal code against billing zip code should treat this as a soft signal, not a hard gate. The accuracy radius of 25 km means the actual location is somewhere within a 25 km circle around downtown Chicago.
Contrast this with a mobile carrier IP, where city confidence might be 30% and accuracy radius 200 km, or a VPN IP, where the geolocation is technically accurate (it does reflect the exit node) but tells you nothing about the user. Your workflow logic should branch on connection type and confidence score, not just on the city name.
From IP Tracker Myth to Geolocation Signal
The phrase "IP tracker" will keep pulling search volume because people want the fantasy version: type in an IP, see someone's house on a map. That will never work. But the real version — a probabilistic system that combines routing data, physics-based measurements, and crowdsourced observations to estimate location within a statistically bounded confidence interval — is genuinely powerful when used correctly.
The key principles: know your accuracy limits by network type, never treat geolocation as identity, use confidence scores to calibrate decisions, combine with behavioral signals for fraud and security, and stay within the legal frameworks that govern IP as personal data. Do all that, and IP geolocation becomes one of the most cost-effective signals in your security and intelligence stack.
DomScan's IP lookup tool returns geolocation with confidence data, ASN ownership, VPN/proxy detection, and abuse contacts in a single query. For automated workflows, the IP Lookup API delivers structured JSON that integrates directly into fraud engines, SIEMs, and compliance pipelines. Use the Reverse IP API to map what domains share an address and build the full infrastructure picture around any IP. Run a domain profile to connect IP intelligence with DNS, WHOIS, and hosting data for a complete view.