How to Validate a GTFS Feed

Why GTFS Validation Matters

A GTFS feed that contains errors will be rejected by Google Maps, Apple Maps, and other trip planners — or worse, it will be accepted but display incorrect information to riders. Validation is the safety check that ensures your data is complete, correctly formatted, and ready to publish.

The good news: most GTFS errors are simple to fix once you know where to look. This guide walks you through the entire validation process so your feed passes on the first submission.

What Does a GTFS Validator Check?

A GTFS validator examines your feed files against the official GTFS specification. It looks for:

  • Missing required files — Every GTFS feed must include agency.txt, stops.txt, routes.txt, trips.txt, stop_times.txt, and calendar.txt (or calendar_dates.txt).
  • Missing required fields — Each file has required columns. For example, stops.txt must include a stop_lat and stop_lon for every stop.
  • Data type errors — Latitudes and longitudes must be numbers. Times must be in HH:MM:SS format. Colour codes must be valid hex values.
  • Referential integrity — Every trip_id in stop_times.txt must exist in trips.txt. Every route_id in trips.txt must exist in routes.txt.
  • Service calendar gaps — Routes should have service defined for upcoming dates, not just past dates.
  • Shape file issues — If you include shapes.txt, each shape must have valid coordinates that trace a plausible path.
Required GTFS Files
  • agency.txt
  • stops.txt
  • routes.txt
  • trips.txt
  • stop_times.txt
  • calendar.txt

Step-by-Step: How to Validate Your GTFS Feed

Step 1 — Assemble your GTFS files

Your GTFS feed should be a ZIP archive containing all required text files. If you built your feed with AddTransit, the platform assembles and zips this for you automatically. If you built it manually, ensure every required .txt file is present in the root of the ZIP — not inside a sub-folder.

Step 2 — Run the validator

Upload your ZIP to a GTFS validator. The validator produces a detailed report categorising issues as errors (must fix), warnings (should fix), and informational notices. AddTransit runs this validation automatically every time you export your feed, so you never need to run it separately.

Step 3 — Resolve errors first

Work through the errors in priority order. Errors will cause your feed to be rejected outright. Warnings may cause data to display incorrectly. Start with any "missing required field" errors, then fix referential integrity issues, then address data type problems. Each error message names the specific file and row number so you know exactly where to look.

Step 4 — Re-validate until clean

After making fixes, re-upload and run the validator again. Repeat until you have zero errors. Aim to eliminate warnings too, especially if you are submitting to Google Maps — a clean feed is processed faster.

Step 5 — Publish your validated feed

Once validation passes, you are ready to publish. Upload your feed to a publicly accessible URL and submit it to Google Maps, Apple Maps, and other trip planners. See our guide on how to publish your GTFS feed to Google Maps for the next steps.

Common Validation Errors and How to Fix Them

If you have run a validator and are looking at the output, the error names can look intimidating — codes like stop_time_with_only_arrival_or_departure_time or decreasing_stop_time_distance are written for software developers, not transit managers. The table below translates the most common ones into plain language so you know exactly what needs fixing. That said, if decoding technical error messages is not how you want to spend your time, this is precisely the problem AddTransit is designed to eliminate — see the section below.

Error Cause Fix
missing_required_field A mandatory column is absent from a file Add the missing column with correct values for every row
invalid_url Agency website URL is malformed Include the full URL starting with https://
stop_time_with_only_arrival_or_departure_time A stop has arrival time but no departure time, or vice versa Provide both arrival_time and departure_time for every stop
decreasing_stop_time_distance Shape distances are not increasing along the route Ensure shape_dist_traveled increases with each stop
service_date_range_too_long Calendar extends more than one year into the future Limit your service dates to a rolling 12-month window

How AddTransit Simplifies Validation

With AddTransit, validation is built into the workflow — not a separate step you have to remember. As you enter stops, routes, and schedules into the platform, it checks your data in real time and flags problems before they reach the export stage. When you are ready to publish, you download a feed that is already validated and ready to submit.

This means you spend less time troubleshooting spreadsheet errors and more time running your service. Agencies using AddTransit typically have their GTFS feed created and ready within a single day. Each journey planner then has its own submission, review, and publishing process before routes appear publicly.

Create your validated GTFS feed with AddTransit

Frequently Asked Questions

AddTransit's built-in validator checks your feed against the same standard that Google uses when reviewing submissions. It runs automatically every time you export your feed.

Yes. Even small updates like changing a departure time can introduce errors if a related field is not updated consistently. Always validate before publishing an updated feed. AddTransit makes this automatic — it validates on every export.

Google will usually accept a feed with warnings, but the warnings may cause some data to display incorrectly in Maps. It is best practice to resolve all warnings before submitting.

Validation itself is fast — typically under a minute for a standard-sized agency feed. The time-consuming part is fixing the errors found. Using a platform like AddTransit that prevents errors as you enter data eliminates most of this work entirely.
Related How-To Guides