Mapping travel time with the Google Maps Isochrones API

An isochrone, from the Greek root words iso (equal) and chronos (time), is a line that connects points of equal travel time around a given location. In urban planning, they underpin ideas like the 15 minute city, where the aim is for residents to reach their daily needs within a short walk or ride. They also expose the opposite: the food deserts, healthcare gaps, and isolated communities where transit access falls short. In this tutorial, I'll show you how to use the Google Maps Isochrones API for a wide variety of applications in last mile delivery, retail, real estate and more!

Part 1: Mapping travel time with the Google Maps Isochrones API (this article)
Part 2: How isochrones work: From shortest paths to polygons
Part 3: Build a travel time map using the Google Isochrone API

Show how far you can travel from a point in a set amount of time using the Google Isochrones API

Mapping travel time and reachability with the Google Isochrones API

What is the Google Maps Isochrones API?

The Google Maps Isochrones API calculates the area reachable within a specified amount of time from a location, and returns the reachable regions as contours of polygons or lines that you can display on a map. An isochrone doesn't answer "how far away is this?". It answers "what can I reach in a set amount of time". And because it follows the real road network instead of drawing a straight line radius, it captures the roads, highways, traffic patterns, and transportation modes that affect how long it takes to get somewhere.

Overlay that reachable area with data on jobs, population, or amenities and you get hard numbers: how many jobs someone can reach by bike in half an hour, or what share of households sit within a thirty minute drive from a popular school.

Google Maps Isochrones API worked example

Here's a quick example of a driving isochrone that starts from downtown Vancouver, BC.

Endpoint POST https://isochrones.googleapis.com/v1/isochrones:generate

Headers
Content-Type: application/json; charset=utf-8
X-Goog-Api-Key: YOUR_API_KEY

Request Body

{
  "location": {
    "latitude": 49.2768282,
    "longitude": -123.1090144
  },
  "travelDuration": "1800s",
  "travelMode": "DRIVE",
  "routingPreference": "TRAFFIC_AWARE",
  "enableSmoothing": true,
  "travelDirection": "FROM"
}

location is the coordinate latitude longitude pair around which to center the isochrone lines.

travelDuration is the time horizon for the isochrone calculation. The API supports a maximum travel time of 3600 seconds (1 hour) for the DRIVE mode, and 7200 seconds (2 hours) for the "WALK" and "BICYCLE" modes.

travelMode is the mode of transport used. It can be one of "DRIVE", "WALK" or "BICYCLE".

routingPreference controls how traffic data influences the generated polygon.

• TRAFFIC_UNAWARE (default): Builds the polygon from speed limits and road hierarchy alone. The result is deterministic i.e. the same request returns the same shape regardless of when you send it, which makes it the right choice for baseline analysis and scenario planning.
• TRAFFIC_AWARE: Uses live and predictive traffic at the time of the request, so the reachable area contracts during congestion and expands off peak. Only available when travelMode is "DRIVE".

enableSmoothing adds a purely cosmetic post processing of the isochrone boundary when set to true. It changes how the polygon looks, not what the routing engine computed.

travelDirection lets you find both the inbound and outbound reachability of the specified location:

• "FROM" (Outbound): Calculates the area reachable from the origin point within the specified time limit. This is suitable for use cases like delivery zones or service coverage.
• "TO" (inbound): Calculates the area from which you can travel to the origin point within the specified time limit. This is suitable for determining catchment zones, like where employees can commute from to reach a central office.

As the map shows, the two isochrones don't quite match. One-way streets, the placement of highway on-ramps and off-ramps, and real time traffic conditions all mean the route into a point isn't the mirror image of the route out.

Response

{
    "isochrone": {
        "geoJson": {
            "type": "MultiPolygon",
            "coordinates": [
                [
                    [
                        [
                            -123.04089955052466,
                            49.345896722245961
                        ],
                        [
                            -123.04388583603397,
                            49.345115056654834
                        ],
                        [
                            -123.04654204969817,
                            49.344082599800913
                        ],
                        //... Rest of coordinate array
                    ]
                ]
            ]
        }
    }
}

The API returns the isochrone geometry as a standard GeoJSON MultiPolygon. This is neat, because it means that you can drop the response straight into a Google Map out of the box.

The Maps Javascript API data layer parses GeoJSON natively. It reads the MultiPolygon, handles the holes and disconnected pieces, and crucially takes GeoJSON's [longitude, latitude] axis order as is without having to reverse them (Google's own LatLng object literal are latitude first). In a React app with the @vis.gl/react-google-maps library, rendering the isochrone is as easy as calling useMap() to give you the map instance, and map.data.addGeoJson() to add the polygon vertices to the data layer.

/*** components/Isochrone.jsx ***/
import { useEffect } from 'react';
import { useMap } from '@vis.gl/react-google-maps';

export default function Isochrone({ geoJson, style }) {

  const map = useMap();

  useEffect(() => {
    if (!map || !geoJson) return;

    const layer = new google.maps.Data({ map });

    layer.addGeoJson({
      type: 'Feature',
      geometry: geoJson,
      properties: {},
    });

    layer.setStyle({
      fillColor: style.fillColor,
      fillOpacity: style.fillOpacity,
      strokeColor: style.strokeColor,
      strokeWeight: style.strokeWeight,
      zIndex: style.zIndex,
    });

    return () => layer.setMap(null);

  }, [map, geoJson, style]);

  return null;
}

Styling is done by passing a standard google.maps.Data.StyleOptions object into layer.setStyle(). Don't worry if you didn't catch all that. Sample working code is available in our google_isochrone_sandbox repo on GitHub.

Why choose the Google Maps Isochrones API?

Mapbox, HERE Maps, TravelTime, and the open source stack (Valhalla, OpenRouteService) have offered isochrones for years. So what makes the Google Maps Isochrones API special? Three things:

Traffic aware isochrones

Unlike Google, both Valhalla and OpenRouteService build on OpenStreetMap road data, which means they calculate travel times from posted speed limits rather than actual traffic conditions. The difference matters. Imagine a real estate portal like Zillow or Trulia using isochrones to show what's within reach of a listing. A traffic unaware isochrone will overstate how accessible those amenities are, promising a 15 minute commute that takes much longer at peak hour.

Data accuracy

Google has spent years building one of the strongest traffic and road datasets in the industry by combining anonymized location data from Google Maps users and Android devices with road network and live disruption feeds from transportation authorities and city governments.

That data advantage shows up throughout the Google Maps APIs, which consistently return travel times close to what real drivers experience on the road at a given time of day. This means that an isochrone from Google reflects the roads people actually use and the speeds they actually travel at. If you are using an isochrone to decide where to buy a house, rent an apartment or build a new Costco, you'd want to use the API with the most accurate data. That means paying for the Google Maps Isochrones API.

Features

The API gives you everything you need to build accurate, good looking isochrones in your app.

• It features three travel modes: WALK, BICYCLE and DRIVE,
• It lets you toggle between TRAFFIC_UNAWARE (free flow speed) and TRAFFIC_AWARE (real time traffic) settings,
• It lets you switch between FROM and TO travel directions to flip the question from "Where can I get to?" to "Who can reach me?".
• It also lets you smooth the isochrone's edges for a cleaner, less jagged shape and,
• It's fast. A 60 minute driving isochrone over a city like Vancouver comes back in 200 - 300 milliseconds.

That said, the Google Maps Isochrone API does have one major drawback. It does not support multi modal travel modes. For a hotel aggregator like Booking.com wanting to show how well connected a property is by public transit, that rules the API out entirely.

Comparing isochrone APIs

As I've noted in my previous posts on Google Maps recent push into route optimization and in-app navigation, Google has spent the last several years playing catch up. So how does the Google Maps Isochrone API compare to its competition?

Google doesn't win on every metric. But the two I care most about are accuracy and real time traffic, and Google beats the market in both. When I show a user an isochrone, I want it to reflect what they'll actually experience on the road, and Google's data is what I trust to do that.

Google Maps Isochrones API use cases

Isochrones show up more often than you'd think, anywhere the useful question is "what's reachable in a given time?" rather than "how far away is it?".

Retail site selection

One classic business problem isochrones solve is site selection: deciding where to open a new store so it reaches the most customers without cannibalizing existing stores. This is a travel_direction=TO use case.

The map above plots every Costco in Metro Vancouver alongside its 30 minute drive-time isochrone. Costco has Vancouver pretty much covered (dark overlapping blue areas have more than one Costco within a 30 minute drive) except for the western tip around the University Endowment Lands.

Real estate commute time search

Say you teach at the University of British Columbia and your partner is a doctor at Vancouver General Hospital. You both bike to work and want to keep each commute under 30 minutes. Where should you live? Draw a 30 minute bike isochrone around each workplace and the overlap appears immediately - right along the border between Kitsilano and West Point Grey. Choosing travel_direction=TO or travel_direction=FROM doesn't really matter here. Bike isochrones look nearly the same in both directions, because cycling routes are usually bidirectional and bike speed barely responds to traffic.

Logistics delivery zones

Logistics providers often use isochrones to determine whether an address falls within a service area.

In Vancouver, Loblaw, one of Canada's largest grocery chains, runs a rapid grocery service called PC Express Rapid Delivery in partnership with DoorDash, with delivery in as little as 30 minutes (Bringing on-demand groceries to 8 million Canadians, Oct 2025). Behind that speed sits a network of dark stores. These delivery-only fulfillment centers allow couriers pick up pre-packed orders and deliver by e-bike to skip the parking that slows cars in the urban core.

Dark stores are the textbook travel_direction=TO use case. DoorDash's real question is "how many customers can we reach within a 30 minute delivery window," which is a reverse isochrone around the store. On the PC Express Rapid Delivery site, customers must enter their delivery address before they can add anything to their cart. This lets the service check whether the address is close enough to a dark store to reach the customer within the advertised 30 minute delivery window.

Google Maps Isochrones API pricing

The Google Maps Isochrones API is free to use while it's in Preview. Google hasn't announced a GA rate yet, so any figure is guesswork. But for a rough sense of the market, Mapbox's comparable Isochrone API starts around US$2.00 per 1,000 requests on its first paid tier and drops toward US$1.20 at higher volumes.

My thoughts on the Google Maps Isochrones API

This post covered what an isochrone is, where they're useful, and how to generate one with the Google Maps Isochrones API. It's genuinely impressive and easy to use, but I'm skeptical about how big a commercial success it'll be. Most companies generate an isochrone once per location, then reuse that polygon as a fixed query area for filtering locations, checking coverage, or driving operational decisions. The recurring API revenue might be thinner than it looks.

The ideal customer might be a real estate portal like Zillow or Redfin, generating a fresh traffic-aware isochrone for every listing so buyers see how accessible an address really is.

Note: The Google Maps Platform terms don't yet spell out caching rules for isochrone data specifically. Based on how Google treats other web service APIs, there is a 30 day limit on cached values, after which you must delete them. It's reasonable to expect similar temporary only caching for isochrones, with definitive terms likely arriving at GA.

This article was written by Afi Labs, a Google Maps Platform Premier Partner and reseller. We build route optimization, navigation, and fleet tracking software on Google Maps, and offer volume pricing on GMP licensing. Talk to an engineer or follow Afian on LinkedIn.

Next: Part 2: How isochrones work: From shortest paths to polygons