Google Isochrones API vs TravelTime Isochrones API

Does Google Maps have an isochrone API?

Yes. Google Maps Platform now ships an Isochrones API, so you can generate a travel time polygon.

Whether you should use Google depends on several things, including which transport modes you need, how important performance is, how many locations you need to process at once, and your budget.

This article compares the TravelTime Isochrone API against Google’s, with measured response times for both, plus the other providers you’re probably also looking at including HERE, TomTom, and Mapbox.

Read more on what an isochrone is here.

API response times

We ran the same 100 driving isochrone requests across London using every major provider. Each isochrone has one origin, a departure at 9am on a Tuesday in the future, and the travel times range from ten minutes to three hours.

Note: The Google endpoint used is traffic_unaware, using typical road speeds. You cannot set a time of day, so it does not account for traffic differences throughout peak and non-peak hours. Google does however offer traffic_aware parameter, which calculates the isochrone for leaving ‘now’, but response times when using this parameter are significantly slower.

The response time is shown in milliseconds.

For one-hour polygons in London, Google takes an average of 4.2 seconds to return the result. TravelTime takes 127ms. That’s a 33x faster response time for the same drive time polygons.

Google’s fastest measured response is 928ms, for the smallest isochrone we tested. It never drops below that. TravelTime’s slowest measured response is 290ms, for a three-hour isochrone — still three times faster than Google’s best result. Across every journey time tested, TravelTime returned in under 300ms and Google never returned in under 900ms.

This performance matters because of where the threshold sits. Anything inside a search needs to come back in roughly 200ms to feel instant. Google’s fastest result is more than four times that, at the smallest size available.

While HERE and TomTom are both fast on small polygons — 27.7ms and 44.5ms at ten minutes — they don’t hold it. HERE’s response time rises 32x across the range, to 882ms at three hours. TomTom rises 15x to 658ms. Mapbox reaches 3,220ms for their largest catchment calculations at the one-hour mark. Targomo taps out at two-hour polygons and takes 11 seconds to return the result.

TravelTime response time increases by just 3.2x across the range — from 90ms to 290ms. From 45 minutes upwards, TravelTime is the fastest provider tested.

Maximum travel time: Google stops at an hour

Google caps drive time isochrones at a one-hour limit. Cycling and walking go to two hours.

TravelTime isochrones cap at four hours, delivering more comprehensive journey time maps.

This is a hard blocker for any Google Isochrone user, and it rules out a set of common use cases:

• Coverage obligations measured in hours e.g. mapping postcodes within 90 minutes of a clinic
• Rural and regional catchments, where an hour of driving doesn’t reach the next town
• Logistics, fleet management and service-area work at depot scale

Transport modes: driving, public transport, cycling, walking

Public transport is where third-party providers most often differ, and it’s the mode that decides the answer for a large share of use cases — property portals filtering by commute, employers assessing office locations, public-sector accessibility work. A driving-only isochrone can’t answer any of them.

TravelTime returns isochrones for driving, public transport, cycling and walking, using timetabled transit data rather than an approximation.

Google, HERE, and Mapbox all fail to return public transit isochrones. And TomTom does not support public transit, walking, or cycling.

Isochrone API pricing

Google Isochrones API is priced per 1,000 requests. The Google isochrone calculations are computationally intensive, with only one isochrone returned per request. This means commercial deployments carry some financial risk.

TravelTime is a fixed annual price with unlimited API requests. The cost is known before you build, and it doesn’t change if the feature drives a lot of usage. This allows TravelTime Isochrone API users to build at scale, without compromise.

Read more about why we price this way and why PAYG pricing fails customers. Get your custom quote by chatting with our team.

Traffic awareness and reproducibility

The default Google Isochrone API endpoint uses the traffic_unaware parameter. This produces a deterministic shape that doesn’t vary by time of day. It therefore does not account for traffic differences throughout peak and non-peak hours.

Google does offer a traffic_aware parameter, which calculates the isochrone for leaving ‘now’. Using live conditions means that the same request returns different shapes at different times.

While this is potentially a draw for organisations that need live traffic data rather than predictive times (the only alternative API in this area is HERE), there is a trade-off. With Google you choose between reproducibility and time-of-day awareness. You can have a stable polygon, or one that reflects traffic, but not both.

With TravelTime Isochrone API, you can set the time of departure or arrival. This accounts for typical traffic conditions throughout the day in that location, to deliver more accurate predicted journey time maps. It’s repeatable, reproduceable, and won’t throw in traffic anomalies.

Try it out in the TravelTime isochrone playground.

Batch and volume: one request, one polygon

Google’s Isochrones API returns a single isochrone per request. The origin is one coordinate pair or one place ID, and the response contains one shape. There is no multi-origin request, and no way to union or intersect the results server-side.

For anything at scale, that means additional network overhead, and your own geometry work to combine shapes afterwards.

TravelTime accepts multiple search locations in a single request and can union or intersect the resulting shapes — a combined area of service across several sites, or the overlap between two. This results in even better performance across multiple isochrones and removes postprocessing steps when combining shapes.

Shape detail

Both providers give users control over the detail of the isochrone shape.

Google offers three named precision levels — low, medium and high — which change the grid cell size used to calculate the area.

Their own documentation flags a caveat on the highest setting: it fits the road network more tightly but can produce holes in the polygon where the road network is sparse. If you don’t specify a level, the service picks one based on the travel duration, which means detail varies between requests unless you pin it explicitly.

TravelTime exposes detail as a numeric scale rather than three buckets, so you can tune it to the job. Coarser for overlays that need to render fast, particularly for longer travel times, and finer for hyper-local analysis where boundary precision is key.

Output formats

Google only returns one format, GeoJSON.

TravelTime returns GeoJSON, KML and WKT. If you’re feeding the isochrones into a database or SQL pipeline rather than a map, that difference is a step you’d otherwise have to write yourself.

Read the endpoint references and supported SDKs in the TravelTime isochrone docs.

Full provider comparison

Verified against TravelTime and Google documentation (3 August 2026).

TravelTime H3: An alternative to isochrones

A polygon isochrone gives you one boundary and a binary answer: inside or outside. It’s the only output Google’s Isochrones API produces.

TravelTime H3 returns something different. It delivers multi-modal journey times indexed to every hexagonal cell inside the reachable area, rather than the single line of an isochrone.

This offers more intuitive insight for users and can boost performance.

Polygon workflows can be computationally intensive and they slowdown further in what follows — testing whether points fall inside complex geometries, intersecting overlapping shapes across hundreds of sites, joining results to demographic or transactional data. With travel times indexed to H3 cells, those become simple filters and joins on cell IDs.

• Overlap is measurable by default: Every cell is unique, so journey times within the boundary are calculated. Cannibalisation, coverage gaps and density fall out of the data rather than requiring geometry operations.
• Joins are fast: Travel time sits alongside any other H3-indexed dataset e.g. demographics, inventory, pricing, with no spatial intersection step.
• Resolution is adjustable: Increase resolution for hyperlocal analysis, decrease for national trends, using the same consistent global H3 grid.
• Results cache cleanly: Cell IDs are easy to store and reuse, so repeat analysis doesn’t mean repeat calculation.

CARTO reports that customers see a 96–99% reduction in processing time across data preparation, spatial enrichment and large-scale analysis using TravelTime H3, without a loss of accuracy.

Google’s Isochrones API has no equivalent — one origin, one polygon, GeoJSON only. If your travel time data is heading into a warehouse, an analytics pipeline or a search index rather than straight onto a map, that’s a structural difference rather than a feature gap.

See why teams are moving from isochrones to H3.

FAQs

Does Google Maps have an isochrone API?

Yes. Google Maps Platform ships an Isochrones API, currently in pre-GA Preview. It generates one isochrone per request for driving, cycling or walking, capped at one hour for driving, and returns GeoJSON. It does not support public transport or multiple origins in a single request.

Does Google’s Isochrones API support public transport?

No. Google’s Isochrones API supports driving, cycling and walking only. Generating a public transport isochrone requires a provider with transit data, such as TravelTime.

What is the longest isochrone Google can generate?

One hour for driving, and two hours for walking and cycling. Google’s documentation attributes the driving limit to the size of the road network that has to be analysed at longer durations. TravelTime supports up to four hours for driving.

How fast is Google’s Isochrones API?

In our testing, Google returned a 10-minute driving isochrone in 928ms and a one-hour isochrone in 4,210ms. TravelTime returned the same shapes in 90ms and 127ms. Google’s fastest measured response was slower than TravelTime’s slowest.

Can Google generate multiple isochrones in one request?

No. Each request takes a single origin — either coordinates or a place ID — and returns a single polygon. Processing multiple locations means one request per location, with potentially more network overhead and geometry work to combine the shapes.

How much does Google’s Isochrones API cost?

Google Isochrones API prices per 1,000 requests, so costs scale with usage. However, this is subject to change because the feature is in Preview.

TravelTime is priced as a fixed annual fee with unlimited requests.

What is the best isochrone API?

It depends on your constraints. Check the hard limits first — public transport support and maximum travel time — because no amount of engineering works around them. Then check locations per request, output formats, and response time at the longest travel time you need rather than the shortest.

What are the alternatives to isochrones?

TravelTime H3 offers a high-performance alternative to isochrones. It delivers multi-modal journey time catchments and calculations the times to/from every cell, not just the outer boundary.

Which isochrone API should you choose?

Google’s Isochrones API is a reasonable choice if you’re already building on Google Maps Platform, you only need driving, cycling or walking, your travel times stay under an hour, you’re generating shapes one at a time, and latency doesn’t matter because the work runs offline.

For a straightforward drive-time overlay inside an existing Google stack, it does the job.

The TravelTime Isochrone API is the better fit when you need a more comprehensive polygon provider:

• You need public transport: This is the one that can’t be engineered around. Commute-based search, employer location analysis, urban planning, and accessibility work all need transit isochrones.
• You need travel times over an hour: Rural catchments, coverage obligations and large-scale depot and delivery service areas routinely do.
• The isochrone is user-facing: At 928ms minimum, Google’s fastest polygon is still too slow to generate inside a page load. TravelTime stayed under 300ms at every travel time tested.
• You’re processing lots of locations: Multiple origins in one request, with server-side union and intersect, replaces orchestration you’d otherwise have to build and maintain.
• Your output goes into GIS: GeoJSON, KML and WKT, rather than GeoJSON alone.
• You need to forecast cost: A fixed annual price with unlimited requests means a successful feature doesn’t become an unpredictable bill.
• You need support and reliability today: Google’s Isochrones API is in pre-GA Preview, which means limited support and the possibility of breaking changes. If you’re embedding isochrones in a production feature, that’s a real consideration.

Try the TravelTime Isochrone API

Get a free TravelTime API key to start building today. Or chat to our team about your project or production deployment. We can talk through request volumes, travel time ranges and the modes you need, and our pricing.

Also useful:

• What is an isochrone? A plain-English explainer
• Isochrone map generator: draw one now, no code required