BigDataCloud vs IPinfo — IP Geolocation Comparison
IPinfo is one of the most technically serious companies in the IP intelligence space. They have built real infrastructure, published genuine research, and made specific claims about their methodology that are worth engaging with honestly. This page does that — it explains what IPinfo does, where their approach works, where it runs into fundamental limits, and how BigDataCloud approaches the same problem differently.
This is not a marketing comparison. It is a technical one.
What IPinfo's ProbeNet actually does
IPinfo's primary differentiator is ProbeNet — a network of over 1,300 servers distributed across roughly 600 cities worldwide. These servers send ICMP ping requests and TCP probes to IP addresses and measure how long the response takes. The claim is that by measuring round-trip time (RTT) from multiple probe locations, they can infer where an IP address is physically located.
This is a genuine and expensive technical undertaking. For the subset of IP addresses it can reach, it produces real signal. The question worth asking is: how large is that subset, and what happens to the rest?
The response rate problem
The vast majority of IPv4 addresses do not respond to external probes. Firewalls block inbound ICMP by default, carrier-grade NAT means that most consumer IP addresses are shared gateways rather than individual devices, and network operators increasingly treat unsolicited probe traffic as hostile. In practice, a single-digit percentage of the IPv4 address space responds to external ping requests — and within that fraction, the addresses that respond are overwhelmingly routers, servers, and network infrastructure.
Consumer IP addresses — the ones a developer is typically trying to locate — almost universally do not respond. They sit behind CGNAT, behind home routers, behind mobile carrier gateways. No probe reaches them.
IPinfo acknowledges this directly in their own documentation. For non-responsive IPs, they state that they "infer likely characteristics using patterns across adjacent IPs, historical RTT baselines, ASN behaviour, and infrastructure signatures." In other words, for the vast majority of the IP address space, ProbeNet does not provide direct measurements. It provides inference from nearby addresses that may or may not be geographically proximate in any meaningful sense.
For IPv6, the situation is more fundamental. The IPv6 address space is so large — 2128 addresses — that systematic probing is mathematically infeasible. Most consumer IPv6 addresses also use privacy extensions that rotate regularly, making any individual address ephemeral. IPv6 probing at scale is not a limitation of ProbeNet specifically; it is a property of the protocol.
The triangulation problem
Even for IP addresses that do respond to probes, RTT-based triangulation does not reliably produce geographic location. Internet routing does not follow the shortest physical path — it follows the lowest-cost path as determined by BGP policy between autonomous systems. A packet from a probe server in Frankfurt to a target in Berlin might travel via Amsterdam or even via transatlantic links depending on peering agreements. RTT reflects routing policy, not physical distance.
Genuine triangulation — inferring location from signal travel time across multiple known reference points — requires the signal to travel at a known speed along a known path. Neither condition holds on the public internet. What RTT measurement from a nearby probe can establish is something more limited: if a probe server in a given city sees a very low RTT to an IP address, that address is probably in the same city or a nearby one. But this only works when a probe exists in the right city to begin with. With 1,300 probes across 600 cities, the approach provides useful signal for a small fraction of the world's IP population and limited coverage elsewhere.
There is a deeper problem even in the best case. Suppose IPinfo does have a probe near a router interface and establishes its precise physical location. That still does not tell you what you actually need to know for geolocation: which geographic area does that router serve? A router physically located in a Frankfurt data centre might serve customers in Germany, Austria, Switzerland, and the Netherlands. A router in London might exclusively serve a single corporate campus three streets away. Physical location of a router and geographic service area of a router are different things — and due to routing policy, they may have little relationship to each other. ProbeNet, at its best, tells you where the router is. BigDataCloud's approach tells you where the users behind it are — which is the question that actually matters.
What BigDataCloud does differently
BigDataCloud's approach is built on two parallel and independent processes that run simultaneously for every IP address. The combination of both — and how well they agree — is what produces our confidence value and confidence area. This is the methodology protected by US Patent No. 11,792,110 B2.
Process 1: Router service area mapping
The internet routes traffic through a hierarchy of routers. When a device connects anywhere, data travels through a chain of routers until it reaches the access or aggregation router — the final router that actually delivers traffic to the end device. That access router serves a specific geographic area. If you know which access router is responsible for a given IP address, and you know that router's service area, you know where that IP is in use.
BigDataCloud continuously maps the entire routable IPv4 and IPv6 address space. We identify and classify every public router interface — distinguishing access routers (which deliver to end users) from core and edge routers (which route between networks). We then calculate each access router's geographic service area using a curated set of IP addresses with verified locations as ground truth. For any IP, we identify its responsible access router and place it within that router's verified service area.
This does involve active network scanning — but of a fundamentally different kind from RTT probing. We are not pinging end-user devices and measuring response times. We are mapping routing infrastructure: which routers exist, what roles they play, and what geographic area each one serves. This can be done non-intrusively, at reasonable scale, without the ethical and technical problems that plague probe-based consumer IP scanning. And critically, the answer it produces is structural: where does this router actually deliver traffic, not how far away does this IP seem based on latency.
Process 2: Field evidence from GPS observations
When a user visits a website or uses an application that calls our free client-side reverse geocoding API and grants location permission, their device provides accurate GPS coordinates. At that moment, we also observe which IP address that device is using. The pairing of a real GPS location with a real IP address is recorded as direct evidence for that IP.
This is not inference. It is direct observation. A user in Sydney on a mobile connection, sharing their GPS location, gives us verified evidence that a particular IP address is in use in Sydney at that moment. No probe can produce this class of information, because probes do not reach consumer devices behind NAT and CGNAT — but real users do use those addresses, and when they share their location, we learn exactly where.
As this evidence accumulates across millions of observations, patterns emerge. Addresses with consistent evidence accumulate precise, stable location data. Dynamic and shared addresses show the geographic spread of their actual usage.
Two processes, one confidence signal
For every IP address, both processes run independently. The confidence value reflects how well they agree. When both processes converge on the same location, confidence is high. When they produce conflicting or sparse results, confidence is lower — and the confidence area polygon reflects the actual geographic range of uncertainty rather than presenting a falsely precise point estimate.
This is the structural difference with IPinfo's approach. ProbeNet produces a point estimate with a statistical radius reflecting measurement uncertainty. BigDataCloud produces a point estimate backed by two independent evidence streams, with a confidence area representing the real-world service geography of the IP — not an error bar around a guess.
A different kind of accuracy
IPinfo publishes an accuracy page showing errors found in competitor data. This is useful context, but it demonstrates competitor errors, not IPinfo's own error rate. Their accuracy claim — "92% match to ground truth" — appears in marketing materials without a published methodology: what ground truth dataset, collected how, across which network types, covering what proportion of the IP space.
BigDataCloud publishes a Daily IP Geolocation Accuracy Report — the only public daily benchmark in the industry. It shows our accuracy across different network types and regions, updated every day, independently verifiable by anyone. We do not ask you to accept a number; we show you the evidence.
There is also a structural difference in how uncertainty is reported. IPinfo's Plus plan includes an "accuracy radius" — a circle around the point estimate that reflects their statistical confidence. BigDataCloud returns a confidence area polygon that represents the actual geographic range of locations that IP has been observed in use. These are conceptually different: a radius is an estimate of how far our guess might be wrong; a confidence area is the real-world service area of the IP address. For fraud detection, compliance, and risk decisions, knowing the actual possible range matters more than a statistical confidence interval around a point estimate.
VPN detection and anonymiser signals
IPinfo markets named VPN detection as a significant differentiator — the ability to identify not just that traffic is coming through a VPN, but which VPN provider specifically. This is worth examining carefully.
True VPN detection at the IP address level requires either device-level access or direct relationships with VPN providers to obtain their IP allocations. No third-party IP intelligence provider has either at comprehensive scale. What VPN detection actually means in practice is maintaining lists of known VPN provider IP ranges — which can only be built reactively, from IPs already observed in use, and which will always represent a fraction of the actual VPN IP space. There are thousands of VPN providers, the IP ranges change, and residential VPNs increasingly use ordinary consumer IP addresses that cannot be distinguished from regular traffic.
The more important question is what a developer actually does with this information. If you are trying to decide how to handle anonymised traffic — whether to challenge it, restrict it, or flag it for review — the actionable signal is: is this a real residential user, or is it automated, infrastructure, or anonymised traffic? The name of the VPN provider does not change that decision. Knowing that an IP belongs to NordVPN versus an unidentified VPN service does not lead to a different action.
BigDataCloud takes a different approach. Rather than maintaining reactive lists of known VPN addresses, we assess the hosting likelihood of every IP address — a proactive classification of whether an address belongs to infrastructure rather than a genuine residential or mobile user. This covers VPNs, proxies, Tor exit nodes, datacenter addresses, residential proxy networks, and any other non-eyeball traffic under a single, actionable signal. Critically, because the assessment is based on the characteristics of the address space rather than prior observation of VPN activity, it can flag infrastructure that has not yet been observed serving VPN traffic — addresses that would not appear on any reactive list.
We do not claim to identify every VPN address. Nobody can. But we believe the right question to optimise for is not "which VPN provider is this?" — it is "is this real human traffic?" Our hosting likelihood model answers that question more reliably and more completely than a partial list of named VPN providers.
Where each approach works best
ProbeNet's approach works well for static infrastructure IPs — server addresses, hosting providers, CDN edge nodes, corporate networks. These addresses respond to probes, tend to be stable over time, and are often in locations where IPinfo has nearby probe coverage. For these use cases, IPinfo is a capable provider.
BigDataCloud's field evidence approach works well for consumer IP addresses — residential broadband, mobile, and CGNAT pools. These are precisely the addresses that probing cannot reach. When a developer needs to understand where their actual users are — not where their hosting provider's servers are — field evidence from real user observations is a more direct and reliable source than inference from network measurements of nearby infrastructure.
For IPv6 specifically, probe-based approaches provide negligible coverage. Our GPS observation method applies equally to IPv4 and IPv6 — any IP address a user connects from can be paired with their GPS location.
Ease of implementation
There is a common perception that BigDataCloud is harder to get started with than IPinfo. That may have been true in earlier versions of the product. It is not true today.
Both services follow the same basic integration pattern: create an account, get an API key, make a REST request. The main differences are in what you get at each step.
With IPinfo, the free tier returns country and continent only. To get city-level data, ASN details, or any security signals, you need a paid plan. The onboarding is clean and the documentation is good.
With BigDataCloud, the free tier returns the full response: city, region, postal code, latitude, longitude, ASN, network type, connection type, and confidence indicators. You get the same data as paid plans — just with a monthly volume limit. No credit card required, API key in under a minute. For client-side applications, our free client-side API requires no API key at all.
Official SDKs are available for the major languages and package managers. The API is also available via GraphQL if you prefer to query multiple endpoints in a single request and return only the fields you need — which can simplify integration for complex use cases. Documentation covers both REST and GraphQL with working examples.
If you have encountered older content suggesting BigDataCloud is difficult to integrate, we would encourage you to try it. The free tier is genuinely free, the full response is available immediately, and there is no setup beyond account creation.
Pricing
| Volume | IPinfo | BigDataCloud |
|---|---|---|
| Up to 50,000/month | Free (country-level only; no city data) | Free (full geolocation including city, ASN, network type) |
| 150,000/month | $49/month (Core plan) | $29.95/month (Bronze) |
| 1,000,000/month | $49/month + overages at $0.54/1k = ~$465/month | $249/month (Silver) |
| 5,000,000/month | $49/month + overages at $0.54/1k = ~$2,755/month | $249/month (Silver) |
| 10,000,000/month | $49/month + overages at $0.54/1k = ~$5,455/month | $849/month (Gold) |
IPinfo's free tier returns country and continent only. City-level geolocation requires a paid plan. BigDataCloud's free tier returns the full response including city, region, postal code, ASN, network type, and confidence indicators — the same data as paid plans, with a monthly volume limit.
IPinfo's overage pricing ($0.54/1k on Core, $0.81/1k on Plus, $1.03/1k on Max) means that applications with variable or growing traffic face significant cost unpredictability. BigDataCloud's plans include optional overage at $0.249/1k on Silver — and the plan volumes are large enough that most applications do not reach overage.
Feature comparison
| Feature | IPinfo | BigDataCloud |
|---|---|---|
| Geolocation methodology | Active network probing (RTT measurement) + WHOIS + inference for non-responsive IPs | Two parallel processes: (1) router service area mapping — identifying which access router serves each IP and its geographic service area (patented); (2) direct GPS observation from real users at the moment of use. Confidence value reflects agreement between both. |
| Coverage of consumer IPs (CGNAT, mobile) | Limited — these addresses do not respond to probes; falls back to inference | Direct — consumer IPs are precisely where our GPS observation method applies |
| IPv6 coverage | Very limited — probing IPv6 at scale is infeasible | Same methodology as IPv4 — GPS observations apply regardless of IP version |
| Uncertainty reporting | Accuracy radius (statistical confidence interval around point estimate) — Plus plan only | Confidence area polygon (actual geographic range of observed IP usage) |
| Accuracy transparency | Proprietary accuracy claims; no published daily benchmark | Daily public accuracy report — independently verifiable |
| Free tier data | Country and continent only | Full response including city, region, postal code, ASN, network type |
| Getting started | Sign up, get API key, make REST request. Free tier returns country and continent only; city-level requires paid plan. | Sign up, get API key, make REST request. Free tier returns full response including city, ASN, confidence indicators. No credit card. Client-side API requires no key at all. |
| SDKs | Official libraries for Python, Node.js, Go, Java, PHP, Ruby, and others | Official SDKs for major languages plus GraphQL interface for flexible multi-endpoint queries |
| Patented technology | No published patents | US Patent No. 11,792,110 B2 |
| GraphQL interface | No | Yes |
| SLA | 99.99% (claimed) | 99.999% |
| Confidence area API | No | Yes — dedicated endpoint |
Summary
Both BigDataCloud and IPinfo take IP geolocation seriously. The difference is in what data each approach can actually reach. Active network probing works for the fraction of the IP space that responds to external probes — primarily static infrastructure. For the consumer IP addresses that constitute the majority of developer use cases, probing cannot reach them, and inference from nearby infrastructure fills the gap.
BigDataCloud's GPS observation method is built for exactly the addresses that probing cannot reach. It produces direct evidence from real users at the moment of use, expressed with honest uncertainty through the confidence area. The daily accuracy report makes our claims independently verifiable rather than asserted.
If your use case centres on locating infrastructure IPs — servers, CDN nodes, corporate networks — IPinfo is a capable choice. If you are trying to understand where your actual users are, BigDataCloud's methodology is more directly suited to that problem.
To explore BigDataCloud's IP geolocation, start with the IP Address Geolocation with Confidence Area API, review the Daily Accuracy Report, or create a free account — full response data included on the free tier, no credit card required.