GTFS Guru vs the MobilityData GTFS Validator

By Igor Akimov, maintainer of GTFS Guru

GTFS Guru is a Rust reimplementation of MobilityData's canonical Java gtfs-validator. It uses the same notice codes and report format, lists every place where its rules differ, and runs faster, mostly because there is no JVM to start. The canonical validator remains the reference, and it is the one to use when you need the official result.

GTFS Guru is a separate open-source project (Apache 2.0) built to match the canonical validator's output, and it checks that match on real feeds before each release.

Same rules and notice codes

Each GTFS Guru release is checked against one specific release of the canonical validator and one specific revision of the GTFS reference. Both are named on the compatibility page (for GTFS Guru 1.0.0 the baseline is MobilityData/gtfs-validator v8.0.1), and every JSON report records them in summary.canonicalBaseline and summary.specRevision.

Notices use the canonical codes and severities, such as foreign_key_violation or missing_required_field, and report.json follows the canonical report format. Scripts that parse the Java validator's report can usually read GTFS Guru's without changes; the two extra summary fields above are the additions.

Parity is tested, not assumed. Twelve pinned real-world datasets from the Mobility Database, chosen to cover flexible services, Fares v2 and pathways, are validated on every commit and compared with the canonical Java validator before every release; an unexplained difference blocks the release. A wider check over fifty more Mobility Database feeds runs before releases as well. The method is described in docs/real-world-parity.md.

Where the results differ

The rule sets are close but not identical. The differences are listed on the compatibility page and fall into a few groups:

Google consumer checks, off by default. Codes such as duplicate_trip and agency_phone_invalid only run with --google-rules. The canonical validator has no equivalent.
Extra checks in --thorough mode. unused_stop, unused_route and unused_agency are reported only when you ask for them.
One extra rule on by default. service_never_active flags a service with every weekday set to 0 and no added dates.
Deprecated codes still emitted. unused_parent_station and missing_prior_day_booking_field_value were deprecated in canonical 7.0.0. GTFS Guru reports them alongside their replacements.
Three columns not required. fare_attributes.txt/transfers, timeframes.txt/timeframe_group_id and transfers.txt/transfer_type are marked Required in the reference, but GTFS Guru does not fail a feed that leaves them empty, for the reasons given on the compatibility page.

Speed

Measured wall-clock time for a full run, both tools writing their normal report files:

Feed	Canonical 8.0.1	GTFS Guru
MBTA Boston (38 MB zip, 5.4M stop_times rows)	10.60 s	2.32 s (4.6x faster)
OVapi Netherlands (198 MB zip, 16.0M stop_times rows)	65.18 s	9.75 s (6.7x faster)
Small feeds (295 test feeds, median 1.6 KB)	1.274 s median	0.0158 s median (88x faster)

Method: the two large feeds were run on an Apple M3 Pro with a warm page cache and 8 threads, GTFS Guru 5 times and the canonical validator 3 times under OpenJDK 21. The small-feed row covers every feed in the project's test corpus, 3 runs each with the median kept, on a Linux x86-64 container; the speed-up there ranges from 28x to 196x, because on a tiny feed JVM startup is most of the run. The rule sets differ, so these are whole-run comparisons, not per-rule ones, and your numbers will depend on your feed and machine. Commands to reproduce are in docs/benchmarks.md.

How each one is distributed

The canonical validator runs on the JVM and is offered as a command-line tool, a desktop app and a hosted web service. GTFS Guru is compiled Rust and ships as:

a browser validator built with WebAssembly, where a file you pick never leaves your device;
a single-binary CLI (gtfs-guru) with SARIF output, --fail-on exit codes and a GitHub Action, described in Validate GTFS in CI;
a Python package (pip install gtfs-guru), see Validate GTFS in Python;
an MCP server for AI assistants, see the MCP guide;
desktop apps for macOS, Windows and Linux.

The CLI also includes gtfs-guru diff to compare two feed versions, --fix to write a repaired copy with safe fixes applied, and README status badges.

When to use the canonical validator

When you need the reference result. MobilityData's validator defines the rules GTFS Guru follows. If a partner asks for its report, or the two tools disagree on a notice listed above, the canonical one is the reference.
When you need rules newer than GTFS Guru's baseline. Check the compatibility page for the canonical release this build was checked against.
For GTFS-Realtime. GTFS Guru validates static GTFS Schedule feeds only. For Realtime feeds, use MobilityData's separate gtfs-realtime-validator.

Running both is reasonable: GTFS Guru for fast checks while you edit and in CI, and the canonical validator as a final check. The canonical project is at github.com/MobilityData/gtfs-validator; GTFS Guru's source is at github.com/abasis-ltd/gtfs.guru.

FAQ

Will a feed that passes GTFS Guru pass the canonical validator?

In most cases, since the rules and codes are shared, but not always. Check the accepted differences for the cases where the two disagree. Neither tool's result is a decision by Google or another consumer, which run their own checks.

Do I need Java to run GTFS Guru?

No. GTFS Guru is compiled Rust, so the CLI is a single binary and the browser version runs as WebAssembly. Only the canonical validator needs a Java runtime.

Does GTFS Guru validate GTFS-Realtime?

No. It validates static GTFS Schedule feeds only. See GTFS vs GTFS-Realtime for how the two formats differ.