How Do I Validate My GTFS Feed?

The easiest way is to drop your GTFS ZIP file into a tool like GTFS Guru. It'll scan your data and show you exactly what needs fixing.

Validating is like proofreading before you publish. It's much easier to fix an error now than to deal with it after your riders see it:

• Validation errors are the usual reason a submission to Google Transit stalls or bounces.

• Small typos can accidentally cancel hundreds of trips.

• It ensures your maps look clean and professional.

• It saves you hours of back-and-forth debugging with Google's support team.

How to Validate with GTFS Guru

Step 1: Go to gtfs.guru

Step 2: Drag and drop your GTFS ZIP file onto the validator (or click to browse)

Step 3: Wait a few seconds for validation to complete

Step 4: Review the results – fix any errors, address warnings

A file you pick from your device never leaves it: GTFS Guru compiles to WebAssembly and validates the archive inside your browser tab. Validating by URL works differently — if the feed host blocks your browser's download, the archive is fetched through gtfs.guru on the way to your browser. The privacy policy describes both paths.

What Gets Checked?

Required files: Are all mandatory files present?

Required fields: Does each file have all required columns?

Data types: Are numbers actually numbers? Dates in correct format?

References: Does every trip_id in stop_times.txt exist in trips.txt?

Coordinates: Are stop locations valid lat/lon values?

Times: Are arrival/departure times in HH:MM:SS format?

Logic: Do times progress forward? Are sequences continuous?

Errors (must fix): These break a requirement of the GTFS specification. Consumers may reject the affected data or read it wrongly, so treat them as blockers.

Warnings (should fix): Usually best practice rather than a rule. The feed may still work, but warnings often point at real data problems your riders will notice.

A note on Google: a clean GTFS Guru report is not a decision by Google. Google runs its own checks on submission, with its own rule set and its own severity classification — something GTFS Guru calls a warning may block a Google submission, and the reverse happens too. Validating first is how you remove the problems both tools agree on; Google's errors and warnings reference is the authority on what Google itself accepts.

Other Validation Options

GTFS Guru Desktop App: Download for Windows, Mac, or Linux to validate offline.

GTFS Guru CLI: Use in scripts and CI/CD pipelines with cargo install gtfs-guru

GTFS Guru Python: Integrate into Python code with pip install gtfs-guru

Canonical Validator: The official Java validator from MobilityData, and the reference GTFS Guru is measured against. Closely compatible notice codes, but the two rule sets are not identical — see where they differ. Slower, and needs a Java runtime.

Google Transit Dashboard: Google validates when you submit, but it's better to catch errors beforehand.

Validation Best Practices

• Validate after every significant change

• Validate the complete ZIP, not individual files

• Fix errors before worrying about warnings

• Also test your feed in a trip planner to see how it displays

Related Questions

• Why was my GTFS feed rejected?

• How do I create a GTFS file?

• GTFS notice guide