IP Data Explained: Every Field an IP Address Lookup Returns, and How Much to Trust Each One

IP Data Explained: Every Field an IP Address Lookup Returns, and How Much to Trust Each One

IP data is everything that can be learned about an IP address without talking to the device behind it: who holds the block, which network routes it, roughly where it is used, what kind of connection it is, and whether it has been seen misbehaving. The lookup dissected below came back with 76 fields. They do not deserve equal trust.

The AS number in a response is a fact read from the global routing table. The city is an estimate. The VPN flag is part observation and part guess, and either can be stale by next week. This post takes one real response, goes through it field by field, says where each value comes from, and rates how much weight it can bear.

Four layers of sources sit behind every IP lookup

The registry layer is the oldest. IANA hands address space to the five regional internet registries (ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC), which allocate it to ISPs and companies and publish the holder, the registration date and the contacts over WHOIS and RDAP. We count in the same layer whatever operators declare about their own space. The main case is geofeeds in the RFC 8805 format, discovered through the registry as RFC 9632 describes. Cloud providers, relay services and the Tor Project publish range files too, and if you want to see what one looks like, open the AWS range list, Apple’s Private Relay egress ranges or the Tor exit list. Those three are examples you can inspect, not an inventory of what we ingest. Declared files are one input among many, and most networks publish nothing at all.

The routing layer is BGP. It says which autonomous system originates which prefix right now, and RPKI says whether the holder authorized that origin. Nobody declares this for our benefit. It is simply how packets get there, which is why it is the most dependable layer of the four.

The measurement layer fills in what nobody declared. Light in fiber covers about 200 km per millisecond, so a 10 ms round trip from a known vantage point puts a host within 1,000 km of it, and several vantage points narrow that down. Router hostnames found through reverse DNS often embed an airport or city code, and traceroute shows which of those routers sits in front of an address.

The behavior layer is what an address has been seen doing: hitting honeypots, appearing in abuse reports, or turning up as the exit we were handed by a VPN or proxy service we subscribe to. It is the only layer that says anything about intent. It also goes stale faster than the other three.

Manual corrections sit on top of all four. Automated processing gets things wrong, so we also review correction requests sent by network operators, trusted sources and ordinary users, and apply the ones that hold up. A correction overrides whatever the layers concluded for that range. If you run the network, a geofeed is the better route, because it keeps correcting itself every time you update it.

SOURCE LAYERS RESPONSE FIELDS Registry: what operators declare RIR WHOIS/RDAP, geofeeds, published ranges Routing: what the network does BGP origin and prefix, RPKI ROAs Measurement: what probes find Latency, traceroute, reverse DNS hostnames Behavior: what the address did Honeypots, abuse reports, VPN subscriptions company connection carrier location, time_zone security
Which layer feeds which part of the response. The dashed line is the published-list share of the security flags: Tor exits, relay egress ranges and cloud ranges.

A real response, annotated

Here is what api.ipregistry.co returned for 216.65.149.37 on September 20, 2026, trimmed to the fields discussed below, with keys sorted by name. The full response also carries country metadata (borders, languages, flag URLs, calling code) and currency formatting rules.

{
  "carrier": { "mcc": null, "mnc": null, "name": null },
  "company": {
    "domain": "20point.net",
    "name": "20 Point Networks LLC",
    "type": "business"
  },
  "connection": {
    "asn": 6079,
    "domain": "rcn.com",
    "is_anycast": false,
    "organization": "RCN",
    "route": "216.65.144.0/20",
    "type": "isp"
  },
  "currency": { "code": "USD", "symbol": "$" },
  "hostname": null,
  "ip": "216.65.149.37",
  "location": {
    "city": "Washington",
    "continent": { "code": "NA", "name": "North America" },
    "country": { "code": "US", "name": "United States" },
    "in_eu": false,
    "latitude": 38.89503,
    "longitude": -77.03654,
    "postal": "20230",
    "region": { "code": "US-DC", "name": "District of Columbia" }
  },
  "security": {
    "is_abuser": false,
    "is_anonymous": true,
    "is_attacker": false,
    "is_bogon": false,
    "is_cloud_provider": false,
    "is_proxy": true,
    "is_relay": false,
    "is_residential_proxy": false,
    "is_threat": false,
    "is_tor": false,
    "is_tor_exit": false,
    "is_vpn": false
  },
  "time_zone": {
    "current_time": "2026-09-20T07:32:09-04:00",
    "id": "America/New_York",
    "in_daylight_saving": true,
    "offset": -14400
  },
  "type": "IPv4"
}

Connection fields are read from the routing table

connection.asn and connection.route say that AS6079 originates 216.65.144.0/20. You can check that against any route collector. RIPEstat shows the same origin, and a ROA with a maximum length of /20 makes the announcement RPKI-valid. This is the part of the response we would bet money on.

It is only wrong while the routing table itself is wrong, during a hijack or a leak, and then for minutes or hours. The Virtualizor incident in August was one such window.

connection.organization is the registered name of the AS holder, here RCN, the US cable operator that now trades as Astound Broadband. connection.type is a classification of that network (isp, hosting, business, education, government or inactive) and is a judgment call on our side, easy for a cable ISP and harder for a company that sells both broadband and colocation out of one AS.

Company fields are read from the registry, and they can disagree with connection

company.name is the holder of the address block, which is often a different party from the network announcing it. ARIN’s RDAP record lists 216.65.128.0/19 as a direct allocation to 20 Point Networks LLC, registered on March 15, 2021, with a postal address in El Segundo, California.

So the block belongs to a California company, a /20 out of it is announced by an East Coast cable operator, and the user is in Washington, DC. None of the three statements is a mistake. The same /19 also has ROAs naming AS1239 and AS7029 as permitted origins, which is what address space looks like when its holder spreads it across several networks. If you geolocate from WHOIS alone, you put this visitor roughly 3,700 km from where they are.

216.65.149.37 REGISTRY (ARIN RDAP) 20 Point Networks LLC El Segundo, California 216.65.128.0/19 registered 2021-03-15 ROUTING (BGP + RPKI) AS6079, RCN US cable ISP 216.65.144.0/20 ROA valid, max length /20 GEOLOCATION (API) Washington, DC postal code 20230 38.89503, -77.03654 about 3,700 km from El Segundo
Three correct answers about one address. The registry names the holder, BGP names the carrier of the traffic, and only the third box is about the user.

Company data has a second limit, and our own field reference is blunt about it: a startup renting desks from WeWork shows up as WeWork. Registries record whoever was assigned the block. They know nothing about tenants.

Location gets weaker with every level of detail

Country is the strongest location field because every layer votes on it: the registry record, the geofeed if there is one, the country the AS operates in, and latency. Region and city lean on geofeeds and measurement. Without a geofeed, a city is an estimate, unless someone who knows better has told us and the correction was accepted.

How good an estimate depends mostly on the access technology. The 2026 study “Lost in the Prefix” compared four commercial databases against 37,302 ground-truth observations and found median errors of 3 to 16 km on fixed broadband and 179 to 207 km on mobile, with fewer than 1 percent of observations in the wrong country. We covered the mechanics, CGNAT and centralized packet gateways, in a separate post.

latitude and longitude deserve the least trust of anything in the response. They are the center of an area, a city or a postal code, printed with five decimals that imply a precision they do not have. The cautionary tale is a farm near Potwin, Kansas, which MaxMind used for years as the default coordinates for “somewhere in the United States” until 600 million addresses pointed at it and the family living there sued in 2016.

One flag changes how to read the whole block. When connection.is_anycast is true, the address is announced from many sites at once and has no single location. We return Brisbane for 1.1.1.1, which is where APNIC, the block’s registered holder, has its offices, while your packets to it are answered by whichever Cloudflare site is nearest to you.

Carrier is null for most addresses, and useful when it is not

The carrier object is filled only for mobile networks. Look up 172.56.10.10 and it reads T-Mobile, MCC 310, MNC 260: the mobile country code and network code from the ITU’s E.212 numbering plan, the same pair a SIM card carries. A non-null carrier means the prefix is used for cellular traffic with very high likelihood.

Its real use is as a modifier on everything else. If carrier.name is set, stop trusting the city, expect many subscribers behind the address, and never block on a single bad event.

Security flags mix published lists, observation and inference

Some of these flags start from something the operator declares. is_bogon comes from IANA’s special-purpose registries and unallocated space, and is never ambiguous (more on bogons here). is_tor and is_tor_exit track the Tor network, whose relays are public by design. is_relay marks relay services such as Apple Private Relay, which pool many users behind shared egress addresses. is_cloud_provider is where published files stop being enough: the largest clouds maintain range files, most smaller hosts publish nothing, and those are identified from registry records, routing and our own detection. Where a declared source exists, the main error mode is the delay between a change and its ingestion. Where none exists, the flag is only as good as the detection behind it.

is_vpn, is_proxy and is_residential_proxy are another kind of claim. Very few VPN and proxy companies publish their exit addresses, so we find them the direct way: we hold real subscriptions to those services and record the addresses they hand out. That part is observation. No set of subscriptions sees every exit, so the rest is guessed, inferred from how an address and the range around it look and behave. A flag on its own does not say which of the two produced it.

The proxy flag is set on our example and is_residential_proxy is not. We have this address as a proxy exit in leased space, not as a node in a residential proxy network. The residential flag marks the other case, a home connection that relays other people’s traffic through a residential proxy network. That is the awkward one: the ISP reassigns the address and the next subscriber inherits the flag until it ages out. is_abuser and is_attacker decay the same way.

To be fair to these fields, they are the reason most people buy IP data at all. Use them as a score input. Blocking on one inferred boolean alone will cost you real customers.

is_anonymous and is_threat add no information of their own. The first is true when is_proxy, is_tor or is_vpn is, and the second when is_abuser or is_attacker is. is_relay and is_cloud_provider feed neither.

Time zone and currency inherit the location’s error

Neither is looked up by IP. time_zone.id is the IANA tz database zone that contains the estimated coordinates, and currency follows from the country through ISO 4217. Currency is therefore as good as the country field, which is very good. Time zone is as good as the region, and it only goes wrong where an estimate lands on the far side of a zone boundary, a real possibility for mobile users in the US, Russia or Brazil.

A trust rating for each field

The ratings below are ours. They describe the kind of evidence behind a field, which predicts how it fails. Outside the routing fields, a value can also be a manual correction, which is a person overriding the evidence for a specific range.

FieldMain sourceRatingHow it goes wrong
connection.asn, routeBGP tablesAuthoritativeHijacks and leaks, for minutes to hours
security.is_bogonIANA and RIR registriesAuthoritativeIn practice it does not
company.name, connection.organizationRIR recordsDeclaredLeased space, stale records, tenants hidden behind a provider
is_tor, is_relay, is_cloud_providerOperator declarations, plus our own detection where none existDeclared and observedLag after a change; hosts that declare nothing
carrierOperator allocations, MCC/MNC planDeclaredMVNOs and roaming traffic appear as the host network
location.countryRegistry, geofeeds, latencyDeclared and measuredVPNs, roaming, satellite, anycast
location.regionGeofeeds, measurementMeasuredRegional ISPs with one central gateway
city, postal, latitude, longitudeGeofeeds, measurementMeasuredMobile and CGNAT; coordinates are an area center
time_zone, currencyDerived from locationInheritedWherever region or country is wrong
is_vpn, is_proxy, is_residential_proxyReal subscriptions to the services, plus inferenceObserved and inferredNew exits missed; wrong guesses; flags outlive an address reassignment
is_abuser, is_attackerHoneypots, abuse feedsInferredShared addresses; one event tars many users
Authoritative Declared Measured Inferred read directly operator-stated estimated guessed connection.asn, route security.is_bogon company.name is_tor, is_relay, is_cloud_provider carrier.mcc, carrier.mnc location.country location.region city, postal, latitude is_vpn, is_proxy, is_residential_proxy is_abuser, is_attacker Editorial rating by type of evidence. It is an ordering, not a measured accuracy percentage.
Trust falls from left to right. Country also draws on measurement, which is why it holds up better than the other declared fields when a registry record is stale. The VPN and proxy flags mix exits observed through real subscriptions with guesses, and are placed by the weaker of the two.

What IP data cannot tell you

It cannot tell you who someone is. An address identifies a network attachment point, and only the ISP can tie it to a subscriber, from its own logs, normally under a court order. Behind carrier-grade NAT even the ISP needs more than the address: one public IPv4 address fronts many customers drawing from the 100.64.0.0/10 shared space, and separating them takes the source port and an exact timestamp. That is why RFC 6302 asks servers to log source ports. The default nginx and Apache log formats still leave them out.

It cannot give you a street address. No field in any IP database is a building, whatever the decimals suggest, and the Kansas farm is what happens when people act as if one were.

It also cannot see through a tunnel. A lookup describes the address that reached your server. For a VPN, a corporate proxy, Private Relay or a roaming phone whose traffic is routed back through its home network, that is the exit, and the person may be a continent away. The security flags exist to tell you when that is likely. They do not recover the real location.

How different teams use it

Fraud teams read the fields against each other more than one at a time. A card issued in France, used from a hosting connection with is_vpn set, is a different transaction from the same card on a French ISP with a carrier attached. Our carding post covers where those checks fit in a checkout flow.

SREs mostly want connection.asn. When traffic triples at 03:00, grouping the access log by AS answers “is this one network or the whole internet” in a single query, and connection.type separates a crawler farm in a data center from an ISP outage that is making real users retry.

Product teams use the fields that tolerate error. Country drives language and currency, and a wrong guess costs one click as long as you offer a selector. Do not hard-lock a user to the detected country.

Compliance is the use that demands the most honesty about confidence. Sanctions screening and state-level rules such as Utah’s SB 73 lean on region-level location and VPN detection, the two weaker parts of the response. Record the evidence you had at decision time.

Querying IP data with curl, an SDK or the batch endpoint

A single lookup is one GET request. The fields parameter filters the response down to what you will use, which matters more for payload size at volume than you might expect.

curl "https://api.ipregistry.co/216.65.149.37?key=YOUR_API_KEY&fields=connection,location.country.code,security"

The client libraries wrap the same call. In Python:

from ipregistry import InMemoryCache, IpregistryClient

client = IpregistryClient("YOUR_API_KEY", cache=InMemoryCache(maxsize=2048, ttl=600))

data = client.lookup_ip("216.65.149.37").data
print(data.connection.asn, data.location.country.code, data.security.is_proxy)

For log enrichment, use the batch endpoint: a POST with a JSON array of up to 1,024 addresses, billed at one credit per address plus one for the request. Deduplicate first. A day of access logs usually collapses to a small fraction of its line count in distinct addresses.

curl -X POST "https://api.ipregistry.co/?key=YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '["216.65.149.37", "172.56.10.10", "2606:4700:4700::1111"]'

Cache with the trust table in mind. Registry and routing fields change on a scale of weeks, location on a scale of days, and inferred security flags within hours, so one TTL for the whole response is a compromise. The ten minutes in the Python example suits a login or checkout path where the flags matter; analytics that only reads country and ASN can keep entries for 24 hours. Key the cache on the address, and for IPv6 consider keying on the /64, since a single subscriber will rotate through many addresses inside it.

Every field discussed here comes back from one Ipregistry call, IPv4 or IPv6, and a value we cannot determine is returned as null. You can run your own addresses through it with 20,000 free lookups to get started.

Frequently asked questions

What is IP data?

IP data is the information that can be attached to an IP address without contacting the device that uses it. It covers the registered holder of the block, the autonomous system that routes it, an estimated location, the connection type, the mobile carrier when there is one, and security flags such as VPN, proxy, Tor or known abuser.

How accurate is the location in IP address data?

Country is right in the large majority of lookups. Accuracy drops with every step down. A 2026 study of four databases measured median errors of 3 to 16 km on fixed broadband and 179 to 207 km on mobile connections, while fewer than 1 percent of observations landed in the wrong country. Latitude and longitude describe an area, never a building.

Can an IP address identify a person or a street address?

No. An IP address identifies a network attachment point, and behind carrier-grade NAT one public address is shared by many subscribers at once. Only the ISP can map an address, a port and a timestamp to a customer, and it does so from its own logs, usually under a court order.

Where does IP address data come from?

From four kinds of sources. Registry records held by the five RIRs, plus files that operators publish such as geofeeds and cloud ranges. The BGP routing table and RPKI. Active measurement such as latency and reverse DNS. And observed behavior, collected by honeypots, abuse reports and real subscriptions to VPN and proxy services. Manual corrections submitted by operators and users are applied on top.

Engage customers with in-app updates using Noticeable Keep users in the loop Ship release notes that get read. Try Noticeable

Get started with 20,000 free lookups: sign up