IP geolocation data is built by mapping ranges of IP addresses to physical locations, then checking those locations against the live network before they ship. Many pipelines stop at the registry record and skip that checking. The result is a confident-looking answer with nothing behind it.
Here is the WHOIS record for a Comcast range, 73.0.0.0/15:
NetRange: 73.0.0.0 - 73.1.255.255
CIDR: 73.0.0.0/15
NetName: POMPANO-4
Customer: Comcast IP Services, L.L.C.
Address: 1800 Bishops Gate Blvd
City: Mount Laurel
StateProv: NJ
Country: US
That is 131,072 addresses. The registrant's admin office is in Mount Laurel, New Jersey. A provider that stops at WHOIS will stamp all 131,072 with "Mount Laurel, NJ" and move on. Query our API for 73.0.0.1 and you get Pompano Beach, Florida, the location for that address and the subrange it belongs to. Other parts of the same /15 can map to their own locations, which is exactly why one registry city cannot be right for all 131,072 at once. Same record, different answer, because one approach reads the paperwork and the other checks where each range actually lives.
This piece walks through how we build the IPGeolocation API data, layer by layer, and which popular accuracy claims fall apart when you ask how the number was produced.
TL;DR
IP geolocation data is built in layers: WHOIS and registry records set a rough floor, self-published geofeeds add operator-declared locations, user corrections feed a review pipeline, and active measurement (ping, traceroute, latency multilateration) checks the result against the live network before it ships. What comes back is cross-checked against multiple signals rather than copied from a single source.
- WHOIS alone is a registration record, not a location. Treat it as the floor.
- Geofeeds (RFC 8805) help, but they go stale and disagree with reality, so we verify them before serving them.
- Active measurement is the layer most providers skip; only about 10% of the public IPv4 space even responds to it, which is why a single technique is never enough.
- Measured accuracy: 99%+ at country level, 90%+ at state, 85%+ at city/locality, and the same on every plan, including the free tier. Paid plans add a per-result
accuracy_radiusandconfidence, not better locations. - Every example in this article was checked against our live API on June 26, 2026.
A Lot of Weak IP Geolocation Data Is Just a WHOIS Guess
Public IPv4 allocations are administered through the five Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), which hand blocks to ISPs and companies and record who registered them. That record is public, free, and easy to parse, which is exactly why so much geolocation "data" is just a tidied-up copy of it.
The problem is that a registration address is where an organization filed paperwork, not where its addresses are used. An ISP headquartered in one city routes traffic to subscribers in hundreds of others. A hosting company registered in Amsterdam runs servers in Frankfurt. Read the registry literally and you place thousands of users on top of a head office.
When that guess is applied to a huge block and pinned to a single point, it stops being a harmless approximation. One widely used geolocation database once defaulted roughly 600 million addresses to the geographic center of the United States, which resolved to a family's farm in Kansas. The result, documented by the Boston Globe, was years of investigators and angry strangers showing up at the wrong house. Bad location data is not a rounding error. It points at real people.
So the registry is only the start. For the concept itself, our guide on what IP geolocation is and how it works covers the basics; this article is about what happens after the lookup.
1. What WHOIS Can and Can't Tell You
WHOIS and RDAP reliably give you the registered resource holder and the allocation. They do not reliably tell you which Autonomous System Number is announcing a prefix right now; that is a BGP fact, read from the routing table rather than guaranteed by a registration record. Location is harder still. It is usually right at the country level for consumer and ISP ranges, but for leased or hosting blocks even the country can miss, and it almost never gets the city. It will not tell you which city a given /24 serves, whether the block was re-leased to a different operator last month, or whether it quietly moved continents. Treating it as the answer is how a Florida cable range ends up labeled New Jersey.
How We Build the Data: A Layered, Weighted, Verified Model
We treat every source as a witness, not a verdict. Registry records, geofeeds, user reports, and network measurements each get a weight based on how reliable they have proven to be, and they are cross-checked against each other. When a high-trust signal contradicts a low-trust one, the high-trust signal wins. Nothing reaches production until it has been checked against the strongest signals available for that block, which is the verification step described below.
That gate is the whole difference. Anyone can ingest a feed and serve it. The work is in deciding what not to trust. It is the same methodology behind our IP security data, which we take apart in how we detect risky and hidden IPs.
Layer 1: Registry and WHOIS, the Floor
This is the base layer and the lowest-weighted one. It establishes the network's owner and a first-guess location, and it anchors blocks that nothing else has touched yet. BGP routing data sits alongside it and tells us which network announces a prefix right now, something the registration record alone cannot. We keep it for its near-complete coverage, but we trust it lightly. It is right often enough at the country level for consumer and ISP ranges, yet for leased, resold, and hosting blocks even the country can be wrong, which is why nothing skips the verification step that follows. On its own, this layer is what many "free IP database" dumps actually are.
Layer 2: Geofeeds, Verified Before We Trust Them
In 2020 the IETF standardized a better idea. RFC 8805 lets a network operator publish its own mapping of prefixes to locations as a simple CSV at a stable HTTPS URL, and RFC 9632 (2024) defines how those feeds are discovered through WHOIS. The operator knows where it deployed a block, so in theory a geofeed is the best source there is.
In practice, geofeeds are early and uneven. A 2024 study presented at ACM CoNEXT, Geofeeds: Revolutionizing IP Geolocation or Illusionary Promises?, found that two years after standardization only about 1.50% of allocated IPv4 prefixes were covered by a geofeed. Worse, the ones that exist are not automatically right. Operators copy a template and forget it, re-lease a block without updating the file, or publish optimistic locations for ranges they resell.
So we do not trust geofeeds on sight. We verify the claimed location against our own active measurements before serving it. When consistent measurements from several vantage points disagree with the feed, the network wins: we lower the feed's weight and investigate the prefix before serving the result. A single weak or ambiguous signal is not enough to override a feed on its own. The most common failure mode is a self-published feed that names a plausible-looking city on one continent while the addresses answer from another. Sometimes a single operator's feed scatters its adjacent blocks across several countries at once. The map below shows a few we verified against the live network.
One caveat, and it is the point of this whole article: this is a moving target. Treat the map above as a point-in-time snapshot, not a live status. IP geolocation is not static. Addresses get reassigned, operators re-announce prefixes, and any mapping can change with time. A feed you trust once goes stale. The fix is to re-verify continuously. If you run a network and want your own ranges right, you can submit a correction or set up a geofeed and we will check it.
Layer 3: Corrections as a Feedback Loop
Users tell us when a location is wrong. The lazy response is to overwrite that one record and call it fixed. We treat each correction as a symptom. A reviewer looks at why the address was wrong in the first place: a stale geofeed, a re-leased block, a measurement gap in a region, and fixes the cause, not just the row. One report about one IP often corrects a pattern affecting thousands.
This is slower than a find-and-replace, and it is the difference between a database that drifts and one that gets better the more it is used.
Layer 4: Active Measurement, the Layer Most Providers Skip
This is where reading records ends and measuring the network begins. Our Vantage Network is a set of measurement points distributed around the world. They ping and traceroute target addresses, and the latency from each known location constrains where the target can physically be, the basis of multilateration. Light in fiber only travels so fast, so an address that answers a European vantage point in two milliseconds is not in Mexico, whatever a geofeed says.
Measurement has one hard limit: Most public IPv4 addresses do not answer active probes. When we scan the public, unreserved IPv4 space, a large share of addresses never answer: a firewall drops the probe, ICMP is filtered or rate-limited, the address is allocated but unused, or the host is simply configured to stay quiet. A snapshot of one of our scans, as of June 25, 2026:
| Category | Count | Share of public space |
|---|---|---|
| Total IPv4 address space | 4,294,967,296 | n/a |
| Reserved, multicast, and special-use (per IANA) | 592,708,864 | n/a |
| Public, unreserved space | 3,702,258,432 | 100% |
| Responded to our active measurement | 371,902,039 | 10.05% |
| Public but did not respond | 3,330,356,393 | 89.95% |
Method note: the public, unreserved space is the total IPv4 space minus the reserved, multicast, and special-use ranges above, and "responded" means an address returned at least one reply to our probes during the June 25, 2026 scan window.
1. Why "Just Ping the Whole Internet" Doesn't Work
About 10% of the public IPv4 space answered. That single number sinks the idea that you can locate the internet by latency alone. Worse, the addresses that do respond are disproportionately routers, servers, and other infrastructure, not the consumer and mobile addresses most lookups care about. So we ping where we can, and for everything else we lean on traceroute path analysis, the hops a packet passes through on the way to a silent host, plus the other layers. Anyone claiming full IPv4 coverage from active measurement is describing a network that does not exist.
Beyond Ping: Multilateration and Where It Breaks
When enough vantage points can reach a host, multilateration comes into play: each measured delay becomes a distance constraint, and the overlap narrows the location. The technique is well studied. The foundational work on constraint-based geolocation showed it works, and it was honest about the limits: network delay is distorted by queuing and by the simple fact that packets rarely travel the straight great-circle path between two points. Congestion, circuitous routing, and sparse measurement coverage all add error.
This is where the hard problems live. Latency-based positioning is strong for well-connected, responsive hosts and weak for addresses buried behind congested or indirect paths. It is one constraint among several. Our research team works on tightening those constraints, and we would rather tell you where the method strains than pretend it does not.
What Accuracy You Can Actually Expect
IP geolocation accuracy is not one number. It depends on how precise you need to be, and it should always come with a measure of confidence. Across our dataset we see roughly:
- Country: 99%+. Reliable enough to drive currency, language, and jurisdiction defaults in production.
- State or region: 90%+. Strong for fixed broadband, weaker at borders and on networks that backhaul traffic across state lines.
- City or locality: 85%+, within a radius. Good in dense metros, looser in rural areas and on mobile networks that route through distant gateways.
The honest part is the radius. On paid plans, every lookup returns an accuracy_radius and a confidence value, so you can decide per request how much to rely on it instead of trusting a marketing percentage:
"location": {
"city": "Columbus",
"state_prov": "Ohio",
"country_name": "United States",
"accuracy_radius": "13.696",
"confidence": "high"
}
A small radius with high confidence is a result you can act on. A large radius is the data telling you to treat the city as a hint and fall back to the region. That is more useful than a flat "city-level accurate" stamp.
The location itself does not change with your plan. The free tier resolves the same city, region, and country from the same cross-checked signals, including the active measurement above. The accuracy_radius and confidence fields are the part paid plans add, so you can read precision per result instead of inferring it.
The Accuracy Claims That Don't Survive Contact With Reality
Buy IP data long enough and you will see some confident numbers. Most of them quietly skip the part where you ask how the number was produced. A few worth questioning:
"Street-level" or ZIP+4 accuracy from IP alone. An IP address resolves to a network, not a mailbox. Pinning it to a street implies a precision the input does not contain. If you need a building, use GPS or consented device location. We cap our published claim at city/locality with a radius for exactly this reason.
"99%+ city accuracy" or a single global accuracy figure. City accuracy varies enormously by country, ISP, and connection type. A single worldwide percentage averages away that variance and tells you nothing about your traffic. This is why we report a per-result radius and confidence instead of one number.
"Full IPv4 coverage" through active measurement. As the scan above shows, about 90% of public IPv4 addresses do not answer a probe. Total coverage from measurement alone is not possible; it requires the other layers, and even then parts of the space are estimates.
"Geofeeds are ground truth." They are self-reported and, per the research above, cover only a small slice of the internet and are frequently stale. A geofeed is a strong input that still has to be verified, as the map earlier shows.
The pattern is the same each time: a claim with no method behind it. The test you can apply to any provider, including us, is simple. Ask how a specific result was produced, and whether you can check it. If the answer is a marketing page, the number is decoration.
Where Geolocation Is More Accurate, and Where It Isn't
Fixed broadband is the easy case: stable assignments, predictable routing, good city-level results. Datacenter and hosting ranges are usually pin-down-able because the servers respond to measurement, which is why the corrections above were possible. The hard cases are mobile networks, where carriers route through regional gateways that can sit a hundred miles from the user, carrier-grade NAT, where thousands of subscribers share one public address, and anonymizing networks. For how routing choices like anycast blur a location, see our explainer on unicast, anycast, multicast, and broadcast.
The takeaway for anyone building on this data: read the confidence, design for ambiguity, and never treat a single IP lookup as proof of where a person is.
Frequently Asked Questions
The main IP geolocation data sources are layered: registry and WHOIS records for ownership and a country-level baseline, self-published geofeeds (RFC 8805) for operator-declared locations, user-submitted corrections, and active measurement (ping, traceroute, and multilateration) to verify the result. Good providers cross-check these sources and update continuously rather than trusting any one of them.
Usually because the data is stale or the address moved. IP ranges get re-leased, operators publish outdated geofeeds, mobile and CGNAT networks route you through a distant gateway, and VPNs or proxies relocate you on purpose. A correct provider re-verifies addresses over time, which is why you can report a correction for a range you control.
Roughly 99%+ at country level, 90%+ at state, and 85%+ at city or locality, with the city figure best read as accuracy within a radius rather than a pin. Accuracy depends on country, ISP, and connection type, so a per-result accuracy_radius and confidence value is more useful than any single global percentage.
We treat a geofeed as a claim to check, not ground truth. Because it is self-reported and often goes stale, we test the claimed location against active measurements from several vantage points; when consistent measurements disagree, we lower the feed's weight and investigate the prefix before serving a result.
Continuously. API data refreshes on a rolling daily cycle, fed by crawlers and data pipelines that run 24/7 across registry data, geofeeds, corrections, and active measurements. Downloadable databases ship on daily or weekly cycles depending on the product. Because addresses get reassigned, freshness matters as much as accuracy.
No. IP geolocation resolves to a network and an approximate location, typically city or metro level, not a street, building, or person. Many people share one public address through home routers, corporate gateways, or carrier-grade NAT. For exact positioning you need GPS or consented device location, not an IP lookup.
Because most of the public IPv4 space does not answer. In our scans, only about 10% of it responds to active measurement; the rest is dropped by firewalls, filtered or rate-limited, or simply unused. For those addresses we lean on traceroute path analysis and the other layers rather than a direct ping.
At ipgeolocation.io, each source carries a weight based on how reliable it has proven, and all sources are cross-checked against each other. When a high-trust signal contradicts a low-trust one, the high-trust signal wins; when the evidence is weak or ambiguous, we hold the result and investigate rather than guess. Nothing ships until it clears that check.
What to Do Next
If you work with IP data, the IP Geolocation API and downloadable databases ship these verified locations, with an accuracy_radius and confidence on every paid lookup so precision is visible per result. And if a range you operate is wrong anywhere, tell us, the correction makes the data better for everyone who queries it next.
