Import & export

GTFS·X reads and writes standards-compliant GTFS ZIPs. Import an existing feed to edit it; export to produce a ZIP you can host or hand to a regulator. Every GTFS file the editor supports round-trips through the cycle unchanged — including the parts it has no editor UI for, like Fares v2.

Export

Click Export GTFS in the top bar. The editor validates first; if any errors are present, export blocks until you fix them (warnings don't block — see Validation). On success you get a ZIP file containing:

• Every required GTFS file (agency.txt, stops.txt, routes.txt, trips.txt, stop_times.txt, calendar.txt).
• Every optional file that has data (calendar_dates.txt, shapes.txt, fare_attributes.txt, fare_rules.txt, transfers.txt, feed_info.txt, frequencies.txt if you used the frequency editor).
• Empty optional files are not exported (no zero-row fare_rules.txt in your ZIP).
• GTFS-Flex files where applicable (locations.geojson, booking_rules.txt, location_groups.txt, location_group_stops.txt).
• GTFS-Fares v2 files where present in the imported feed (round-trip preservation — see Fares).
• feed_info.txt always — synthesized from agency data if you didn't fill it in explicitly.
• A provisional external_id column on agency.txt, whenever any agency in the feed has an NTD / External ID set. It carries each agency's own identifier and is not part of the GTFS spec — see NTD ID & FTA reporting. No agency has one, no column is written.

The ZIP is named after the project slug, with the export date appended (sunny-valley-transit-20260518.zip). Drop it on a static host, hand it to Google Transit Partners, or use the editor's hosted publishing to serve it from a stable URL.

Import

Click Import in the top bar, select a ZIP. The editor parses every supported file and surfaces an import summary:

• Counts — agencies, routes, stops, trips, stop_times, shapes, calendars, fares, flex zones, transfers.
• Warnings — unknown route types, malformed values, and anything in the ZIP the editor couldn't make sense of.

After import, the editor loads the feed and you can edit it. Subsequent export produces a ZIP that's structurally identical for every file the editor supports.

Import individual routes from another of your feeds

You don't have to import a whole feed. With a project already open, you can pull a few routes (with their stops, shapes, trips, and service calendars) from any of your other GTFS·X feeds into the current one. This is the fast way to reuse a route you've already built.

1. Open the feed you want to add the routes to (your current project).
2. Click Import in the top bar. The dialog title reads Import GTFS feed or routes when a project is loaded.
3. Switch to the Routes from my feeds tab (available when you're signed in), then pick one of your feeds (published or draft).
4. Choose Import selected routes, tick the routes you want, and click Import N routes.

The selected routes merge into your open project. IDs are automatically prefixed if they would collide; stops are matched to your existing stops by name and location where they line up; and a service calendar is reused when its weekly day-pattern matches one you already have (for example an imported Mon–Fri service folds into your existing Weekdays). Your other feed is never modified, and the whole import is one undoable step.

To import an entire feed instead, use Replace project (or import from a ZIP, URL, or the public catalog on the other tabs).

Round-trip behavior

The principle: every GTFS file and field the editor supports goes out the way it came in, whether or not the editor has a UI for authoring it. Specifically:

• GTFS-Fares v2 is fully round-tripped — every v2 file imported (fare_products, fare_leg_rules, fare_transfer_rules, areas, networks, timeframes, rider_categories, fare_media) reappears on export, even where there's no editor UI for authoring it today.
• GTFS-Flex — locations.geojson, booking_rules.txt, location_groups.txt, location_group_stops.txt, and the extended stop_times fields.
• directions.txt, frequencies.txt, pathways.txt, levels.txt — supported on import; partially supported in the editor; written back on export.

Limits

• 100 MB import size. The browser-side import handles up to a 100 MB ZIP. Larger feeds (transit agencies the size of NYCT, MBTA) exceed this; those agencies typically have their own engineering pipelines and aren't the editor's target audience anyway.
• ZIP only. Import expects a ZIP archive. Raw text files in a folder don't import directly; zip them first.
• UTF-8 expected. Files in non-UTF-8 encodings (Windows-1252, ISO-8859-1) won't parse cleanly. Convert to UTF-8 before importing — the canonical GTFS spec requires UTF-8 anyway.

Edge cases and gotchas

• Importing replaces the current project. Edits you haven't saved get overwritten. The editor prompts before replacing; if you want to keep the current project, save it as a snapshot first or sign in and save to the cloud.
• BOM at the start of CSV files. Some Windows-authored feeds have a BOM that confuses parsers. The editor strips it; the canonical validator does too. Other consumers may not.
• shape_dist_traveled is recomputed on export. The editor uses geodesic length from the shape geometry on every export, even if the imported value was different. This is the right behavior for consistency, but agencies with hand-tuned distances will see the values change.
• Empty optional files trip up some validators. The editor's "don't export empty optional files" behavior is correct per spec but occasionally surprises consumers who expect to see a fare_rules.txt present-but-empty. If you need an empty file to satisfy a downstream check, add a stub fare to keep it populated.