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.
This post explains the distinction and why it matters, especially for edge cases like in-flight WiFi.
Two Products, Two Questions
IP geolocation 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 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.
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:
{
"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:
{
"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:
*Even on Max, in_flight, in_transit, and public_space still return null coordinates
| Tier | Places coverage |
|---|---|
| Lite | No Places data |
| Core | is_place flag only, no name, category, or coordinates |
| Plus | place.name and place.category, no ssid or coordinates |
| Max | Full place object, including ssid, latitude, and longitude (where applicable) |
Even on Max, 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.