Skip to content

Free tool · live search, rate-limited

Round-Trip Planner

Out and back, priced as one itinerary rather than two searches stapled together. Each row shows both legs with their own airlines, stops and durations, and one total for the pair.

7 nights. One REAL paired-leg search on our key, capped per visitor per day. Round trips take longer than one-ways: allow ~10-30s.

LHR ⇄ JFK

nothing searched yet

Set two dates and press Price the trip. Each row that comes back is one itinerary: the outbound and the return with their own airlines, stops and durations, and one total price for the pair. No stale sample sits here in the meantime, because a fare captured last month is not information.

Know before the response shape changes

One email when something ships that changes what you can build: a new endpoint, a changed field, a deprecation, a price move. Nothing else goes to this list.

The address is stored to send that list and nothing else. It is not sold, not shared with the marketplaces, and not used to build a profile. Unsubscribe from any email, or from the unsubscribe page. More in privacy.

Why a round-trip endpoint exists

Two one-ways is a different question, and usually a different price

This is the part of the flights API that most alternatives do not model at all.

Paired legs, one total

The endpoint returns itineraries, not fares. total_price is the price of the pair, which is the number a booking engine would charge you.

Both sides described

departure_flight_airline, stops and duration, and the same three for the return leg. A cheap total with an overnight connection is visibly different from a cheap total without one.

One request

Trip length is just the return date. Sweep it across a range on your own key and you have a trip-length comparison, still one request per candidate.

On your own key

One trip here. Every trip length, every week, on your key

The same request, fired in parallel across return dates, is a trip-length sweep. It is one line of code and a loop.

Questions, answered plainly

Why not just add two one-way searches together?
Because the answer is usually wrong. Airlines price a return as a product, not as two halves, so the total of two one-ways is often higher than the return fare and sometimes lower than anything you can actually buy. This tool calls the round-trip endpoint, which returns paired legs and one real total for the pair.
What comes back for each itinerary?
The total price and total price as a number, then each leg separately: departure and arrival descriptions, airline, stops and duration for the outbound, and the same four for the return. That is what lets you tell a cheap total with a 14-hour layover apart from a cheap total without one.
Is it free, and is it live?
Both. No account and no email, and every run is a real search against live Google Flights on our key, which is why runs are capped per visitor per day.
Why did a search return nothing?
Round trips fail differently from one-ways: a return date that nothing serves, or a turnaround too short to fly, gives a genuinely empty result. The API reports that in an X-Search-Status header as "empty", and reports a search that did not finish as "degraded", so you can tell the two apart instead of guessing.
Can I compare trip lengths?
Change the return date and run it again. Each run is one request. Doing that across five or ten trip lengths at once is exactly the sort of thing to do on your own key, in parallel, rather than one click at a time here.