# IP Geolocation vs. Places Geolocation: Two Different Questions

**URL:** <https://community.ipinfo.io/t/ip-geolocation-vs-places-geolocation-two-different-questions/7407>\
**Category:** General\
**Created:** [August 23, 2026, 11:57am UTC](https://community.ipinfo.io/t/ip-geolocation-vs-places-geolocation-two-different-questions/7407 "2026-08-23T11:57:27Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Abdullah](https://yyz1.discourse-cdn.com/flex035/user_avatar/community.ipinfo.io/abdullah/32/4973_2.png) [@Abdullah](https://community.ipinfo.io/u/Abdullah)\
**Post date:** [August 23, 2026, 11:57am UTC](https://community.ipinfo.io/t/ip-geolocation-vs-places-geolocation-two-different-questions/7407/1 "2026-08-23T11:57:27Z")

</div>

If you have looked up the same IP address across different IPinfo products and noticed two different sets of coordinates, this is expected. IP geolocation and Places geolocation answer two different questions. This post explains the distinction and why it matters, especially for edge cases like in-flight WiFi.

 ![image](https://canada1.discourse-cdn.com/flex035/uploads/ipinfo/original/2X/4/4f4cc9baadf43eaf9f2f7476a6b174e2486ed04b.jpeg)

This post explains the distinction and why it matters, especially for edge cases like in-flight WiFi.

## Two Products, Two Questions

**[IP geolocation](https://ipinfo.io/developers/ip-geolocation-api-data)** answers: what general area is this IP in?

The `latitude` and `longitude` returned by IP geolocation represent the centroid of the broader locality the IP resolves to. This could be a postal code, a neighborhood, or a city. It is not an exact address. It comes with a `radius` field, which states the accuracy estimate in kilometers for that geolocation call.

**[Places](https://ipinfo.io/data/places)** answers: where exactly is this venue?

The `latitude` and `longitude` returned by Places mark the building-level location of a matched business or public venue, such as a hotel, airport, museum, or stadium. Places identifies real-world venues by matching IP addresses observed on venue WiFi networks.

 ![image](https://canada1.discourse-cdn.com/flex035/uploads/ipinfo/original/2X/8/8fb8784f02e5482ea86b94c079dcf34f36925c7b.png)

Looking up the same IP across both products can return two different coordinate pairs. Both are correct. They are just answering different questions.

## Why This Matters for Moving Locations

Places covers 57 categories across 10 category groups. Most of these categories are fixed venues (a hotel, a museum, a stadium), so a building-level coordinate makes sense.

Three categories are different: `public_space`, `in_transit`, and `in_flight`. These describe WiFi on the move, not a fixed address. A plane in flight is not a building. For these three categories, Places simply does not return `name`, `latitude`, or `longitude`, because there is no fixed venue to point to.

This is worth being precise about: the fields are absent, not present with a `null` value. Nothing in the response claims a coordinate and then nulls it out. The fields are left out entirely, the same way `name` is left out for these categories. This is a deliberate design choice, not missing data. Returning a fabricated coordinate for a moving plane would be misleading. The `category` and `ssid` fields still tell you the IP is associated with in-flight WiFi, which is useful information on its own.

## What This Looks Like in Practice

Take an IP seen on in-flight WiFi. The Places response looks like this. Note that `latitude` and `longitude` do not appear at all, rather than appearing with a `null` value:

```auto
{
  "ip": "184.169.46.4",
  "category": "in_flight",
  "ssid": "SouthwestWiFi"
}

```

Meanwhile, the IP geolocation response for the same IP might return a city-level coordinate, since general geolocation is still available even when Places has no fixed venue to report:

```auto
{
  "city": "Paris",
  "country": "France",
  "latitude": 48.85341,
  "longitude": 2.3488,
  "radius": 20
}

```

The city-level coordinate here reflects the general geolocation of the IP range, often tied to the airline’s ground infrastructure or gateway registration. It does not represent the plane’s real-time position. Treating it as the passenger’s exact location would be inaccurate.

## Tier Availability

Places data availability depends on the API plan:

 ![image](https://canada1.discourse-cdn.com/flex035/uploads/ipinfo/original/2X/3/34ec9ab004096c74ef8ded142912b6f89f9770b2.png)

\*Even on Max, in\_flight, in\_transit, and public\_space still return null coordinates

| Tier | Places coverage |
| --- | --- |
| [Lite](https://ipinfo.io/developers/lite-api) | No Places data |
| [Core](https://ipinfo.io/developers/core-api) | `is_place` flag only, no name, category, or coordinates |
| [Plus](https://ipinfo.io/developers/plus-api) | `place.name` and `place.category`, no `ssid` or coordinates |
| [Max](https://ipinfo.io/developers/max-api) | Full `place` object, including `ssid`, `latitude`, and `longitude` (where applicable) |

Even on [Max](https://ipinfo.io/developers/max-api), `in_flight`, `in_transit`, and `public_space` categories will not return coordinates, since the underlying rule is about the nature of the location, not the plan tier.

## Takeaway

When answering “where is this IP,” check both `geo` and `place` fields, and read them for what they actually represent. `geo` gives a general area estimate with a defined accuracy radius. `place` gives an exact venue when one exists, and returns null coordinates when the connection is on the move. Combining both gives a more complete and honest picture than relying on either alone.