How Can You Inspect a GTFS ZIP from the Command Line?
From the earlier reference collection. Read the current software blog.
List a schedule archive’s contents, extract only the files you need, and check their headers before writing a parser.
Start with the archive listing
A GTFS schedule feed is commonly distributed as a ZIP containing text tables. Before extracting it, inspect the archive’s file list. The unzip -l feed.zip command shows member names, sizes, and timestamps without writing those members into your working directory. This first pass can reveal whether the archive has the expected tables, whether files are nested under an unexpected directory, and whether a supposed feed download is actually an HTML error page.
For example, a listing with agency.txt, stops.txt, routes.txt, trips.txt, and stop_times.txt suggests a recognizable schedule structure. A listing containing only index.html or a directory full of unrelated files is reason to stop and check how the file was obtained. Names alone do not establish that the feed is valid, but they help avoid processing an obviously wrong input.
Extract only the tables you need
When investigating one question, extract the relevant members rather than unpacking the entire archive into a shared directory. For instance, unzip -p feed.zip stops.txt | head streams the beginning of a member to the terminal without creating a copy. To save just two tables, use unzip feed.zip agency.txt stops.txt -d scratch/feed. Choose a new, empty scratch directory so files from an earlier archive cannot be mistaken for current data.
Treat archive paths as input to inspect. If members have a common prefix such as export/stops.txt, use the exact listed path when extracting. A failed extraction may simply mean the member name differs from what you assumed. Avoid extracting an untrusted archive as an administrator or into a directory containing important files.
Check headers before processing
Read the first line of each extracted table, or stream it with unzip -p. A comma-separated header should identify the columns your processing step expects. In a schedule feed, for example, stop_times.txt contains fields used to connect trips, stops, and arrival or departure times. The GTFS reference describes the feed’s files and field definitions; use it to check a table’s intended structure rather than inferring meaning from a filename alone.
Do not rely on head -n 1 as a complete CSV validator: quoted fields and unusual encoding can complicate parsing. It is a quick visual check, not proof that every row is well formed.
Make the inspection repeatable
Keep the original ZIP unchanged and record its filename or checksum alongside notes about what you inspected. If the expected files are present but a parser later fails, you can distinguish an archive-layout problem from a data-content problem. A short inspection routine—list, select, extract, check headers—makes a useful first step before any larger import.
For a formal schema check, compare the tables and fields with the [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/). It explains which files and fields comprise a feed, helping you decide whether a missing column is optional, conditionally required, or a genuine mismatch.