Google Flights compares one origin and one destination across airlines and shows you the itineraries. This service turns that comparison into a table - one row per itinerary, carrying the airline, the departure and arrival times, the journey length, the number of stops and the fare shown.
Flight pricing moves faster than almost anything else you can scrape, and Google is explicit about how much of it is conditional.
Google's own help material says that fares, taxes, fees and even which flights are available to buy can vary by city because of airline business rules, and that the currency shown to you may not be the currency you are eventually charged in. It also notes that the location you search from affects the results, including which booking partners appear. So a price in this export is what Google displayed, for that route, on that date, to a viewer in a particular place - not a universal price for the seat.
The same is true across time rather than space. Prices change with the day of the week you are searching for and with the day you happen to search on. An export captured this morning and one captured tonight are both correct and are not the same measurement. Anything you build on this data should record the moment of capture as carefully as it records the fare.
None of that makes the data less useful - it makes it a time series rather than a lookup. A single pull tells you what a route costs right now. The same pull repeated on a schedule tells you how a route behaves, which is the question most people are actually asking.
There is no URL to copy. You give it a route and a date.
departure_date.return_date for a round trip, or leave it out for one-way.Both dates are UNIX timestamps in the published reference. Departure defaults to the current date if you omit it.
These are the columns this scraper's export declares, in the order the header lists them. Each description explains what the column is for and what Google Flights shows in that position on a results page.
origin this is the route the row belongs to, which matters once a file holds more than one search.Two columns are about the search, not the flight. departure_date, return_date and query echo what you asked for, which is what lets one file hold many routes and dates at once - keep them, and key on them when you compare runs. And do not compute journey length from the two clock times: departure_time is local to the origin and arrival_time is local to the destination, so the arithmetic is wrong on every route that crosses a time zone. duration is the column that already knows this.
None of these are quirks of the scraper. They are properties of how air fares work, and they decide what the export can honestly support.
A fare is only true at the instant it was shown. Google's own guidance is that prices move with the travel date and with airline rules, and that availability itself changes. Store the capture time beside every row and treat the pair as the observation. A price table without run times is a table of numbers you can no longer interpret.
Google states that fares, taxes, fees and the flights available for sale can differ by city, that the location you pick affects which booking partners appear, and that the displayed currency may not be the one you are charged in. For a price comparison to mean anything, hold the search locale constant across the runs you intend to compare - and write down which locale that was, because no column records it.
departure_time is local to the origin and arrival_time is local to the destination. Subtract one from the other on a transatlantic route and you will get an answer that is wrong by hours - sometimes negative. duration is the column that already accounts for the offset and for connection time, and stops is what explains why two itineraries on the same route differ by half a day.
Flight search is one of the most aggressively protected surfaces on the web, and this service is recorded internally as needing a residential proxy - a request that trips the defences gets a page with no flights on it rather than an error. Treat an empty result as a retry condition rather than as "no flights on this route", and schedule accordingly. This is not hypothetical for us: see the closing note about our own runs.
Where a route comparison is more useful as a table than as a results page.
The question is rarely "what does this flight cost" and almost always "is this a good time to buy". Run the same route and date on a schedule, keep every row with its capture time, and you have the price history that a single search can never give you - including how far ahead the fare starts climbing.
Corporate travel rules are written in the abstract - cheapest fare, no more than one stop, arrive before nine. Pull the routes your people actually fly and you can test those rules against real itineraries: how often the direct flight is worth the premium, and how much a preferred-carrier policy costs you per trip.
Across a set of routes, airline, stops and duration describe the competitive shape of a market - who offers the only direct service, where a connection is the norm, which carriers price against each other. That is route-level intelligence you would otherwise buy from an aviation data vendor.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that it is pay-as-you-go.
For every new account, one time. No credit card. All scrapers unlocked. A single route on a single date is a modest number of itineraries, so the free tier covers a genuine first experiment rather than a token one.
Roughly $2 per 1,000 itineraries. Because the value here comes from repetition rather than breadth, the sensible way to spend is a narrow set of routes sampled often - the same route every day for a month costs very little and answers a question a one-off search cannot.
Volume pricing, SLAs, dedicated workers and tailored onboarding for teams tracking many routes and departure dates on a repeating schedule. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.The rest of a journey is a place to stay and a reason to go. These two cover the ground either side of the airport.
Who ranks for the routes and destinations you care about - the airlines, agencies and comparison sites competing for the same traveller.
Accommodation for the same dates and the same destination, so a trip can be costed end to end rather than one leg at a time.
Short answer: yes. A published fare is an advertisement, shown to every traveller who searches the route.
Google Flights results are public. Anyone can search a route without an account, and collecting publicly visible pricing for research and comparison is long-settled practice. As long as the data is publicly available and the process does not disrupt the service, there are no federal laws against it.
The subject matter is uncontroversial. Every one of these eleven columns describes an itinerary - a route, a carrier, a time, a duration, a fare. There is no personal data anywhere in the export: no passenger, no booking, no traveller. Nothing in the file identifies a person, and no booking is made on your behalf.
Google's terms restrict automated access, so this remains a question of terms. We touch nothing behind a login, book nothing, run no third-party trackers on the data layer, and your exports self-delete after 30 days.
The questions we hear most. Something else? Talk to us - humans write the answers, not bots.
origin, destination, airline, departure_time, arrival_time, duration, stops, price, departure_date, return_date and query. One row per itinerary. Note that query comes last here rather than first, which is unusual across our services.departure_date and return_date, both as UNIX timestamps. Departure defaults to the current date if you leave it out.return_date. The reference is explicit that if it is not supplied, only departure_date is used. The column still appears in the export; it is simply empty on those rows.departure_time is local to the origin airport and arrival_time is local to the destination, so subtracting them is wrong on any route that crosses a time zone, sometimes spectacularly. Use duration, which already accounts for the offset and for connection time.stops is how many times the itinerary touches down between origin and destination, with zero meaning direct. On a connecting journey the airline field may name more than one carrier, and the marketing airline is often not the one operating the aircraft.Give it two airport codes and a date, and take the itineraries away as rows - airline, times, duration, stops and the fare shown. Your first 500 rows are free.
Google Flights is where a very large share of air travel research begins. It compares one origin against one destination across carriers and dates, and presents the result as a list of itineraries: who flies it, when, how long it takes, how many times it stops and what it costs. That interface is built for choosing a flight. It is not built for any question about a route over time - whether a fare is climbing, how much the direct service commands over the one-stop, which carriers actually compete on a city pair. This service answers those by turning a route search into a table: one row per itinerary, eleven columns, exported as CSV, JSON or Excel.
Driving it is deliberately simple. The published reference takes each query as a pair of airport codes - origin first, destination second - with the outbound and inbound dates supplied separately as UNIX timestamps. Leave the return date out and the search is one-way; the reference states plainly that only the departure date is used in that case, and departure itself defaults to the current date. Language and region parameters are available on top, and setting them matters more here than on most services, because of what they do to the prices.
The central thing to understand about this data is that a fare is a moment rather than a fact. Google's own material is unusually direct about this: fares, taxes, fees and even which flights are available for sale can vary by city under airline business rules; the location you search from affects the results including which booking partners are shown; and the currency displayed is not guaranteed to be the currency you are eventually charged in. Prices also move with the travel date and with the date you happen to search on. None of that makes the export unreliable - it makes it a time series. Record the capture time alongside every row, hold the search locale constant across runs you intend to compare, and a single ambiguous price becomes a trend you can act on. One further trap worth naming: departure_time is local to the origin airport and arrival_time is local to the destination, so subtracting one from the other gives a wrong answer on any route crossing a time zone. The duration column already accounts for the offset and for connection time; use it.
One honest note about the evidence behind this page. Everything above is either the export's declared schema - the eleven column names, identical in the header of all six of our local runs - or a documented property of the request, or a published statement by Google about its own product. There are no scrape results here, because we have none: every one of those six runs returned an empty array. The reason is recorded internally and is worth repeating, because it is also the most likely thing to happen to you: the service needs a residential proxy, and a request that trips Google's defences comes back as a page with no flights on it rather than as an error. So this page quotes no fare, no airline, no duration and no itinerary count, and none will be added unless a real export backs them. What it does describe - what each column is for, and how Google Flights behaves - is accurate. Start free: your first 500 rows cost nothing and need no credit card.