About

MTA GTFS Realtime feeds are distributed as Protocol Buffer binaries conforming to the gtfs-realtime.proto schema. Decoding these in a browser has historically required either a server-side proxy or a bulky protobuf library. This tool implements a complete protobuf wire format decoder in pure JavaScript, parsing LEB128 varints, length-delimited fields, and fixed-width values directly from the binary. Drop a .pb or .bin file and receive structured JSON mapped to GTFS Realtime field names: FeedMessage, TripUpdate, VehiclePosition, Alert, and all nested descriptors. The decoded JSON output is typically 5× to 15× larger than the source binary. This tool approximates field types based on the canonical GTFS-RT proto definition. Custom extensions or non-standard fields decode as raw wire-type values with numeric field IDs preserved.

Formulas

Protocol Buffer fields are encoded as a tag-value pair. The tag is a varint combining the field number and wire type:

tag = (field_number « 3) | wire_type

Extracting the components:

wire_type = tag & 0x07

field_number = tag » 3

Varints use LEB128 encoding. Each byte contributes 7 bits of payload. The MSB indicates continuation:

value = n∑i=0 (byte_i & 0x7F) « (7 ⋅ i)

Signed integers use zigzag encoding to keep small negative numbers compact:

sint = (n » 1) ^ −(n & 1)

Where tag is the encoded field identifier, field_number is the proto schema field index, wire_type is one of {0, 1, 2, 5}, byte_i is the i-th byte of the varint, and n is the unsigned varint value before zigzag decode.

Reference Data

Feed ID	MTA Subway Lines	Endpoint Suffix	Approx. Update Interval	Typical Binary Size
1	1, 2, 3, 4, 5, 6, S (42nd)	gtfsrt/1	30 s	200 - 800 KB
26	A, C, E	gtfsrt/26	30 s	150 - 600 KB
16	N, Q, R, W	gtfsrt/16	30 s	100 - 500 KB
21	B, D, F, M	gtfsrt/21	30 s	100 - 500 KB
2	L	gtfsrt/2	30 s	20 - 100 KB
11	SIR (Staten Island Railway)	gtfsrt/11	30 s	10 - 50 KB
31	G	gtfsrt/31	30 s	20 - 80 KB
36	J, Z	gtfsrt/36	30 s	30 - 120 KB
51	7	gtfsrt/51	30 s	20 - 100 KB
Wire Types in Protocol Buffers
0	Varint (int32, int64, uint32, uint64, sint32, sint64, bool, enum)		LEB128 variable-length encoding
1	64-bit (fixed64, sfixed64, double)		Fixed 8 bytes, little-endian
2	Length-delimited (string, bytes, embedded messages, packed repeated)		Varint length prefix + payload
5	32-bit (fixed32, sfixed32, float)		Fixed 4 bytes, little-endian
GTFS Realtime Entity Types
TripUpdate		Predicted arrival/departure times for stops along a trip
VehiclePosition		Current geographic position and status of a vehicle
Alert		Service alerts affecting routes, stops, or the network
Common GTFS-RT Enum Values
0	ScheduleRelationship		SCHEDULED
1	ScheduleRelationship		ADDED
2	ScheduleRelationship		UNSCHEDULED
3	ScheduleRelationship		CANCELED
0	VehicleStopStatus		INCOMING_AT
1	VehicleStopStatus		STOPPED_AT
2	VehicleStopStatus		IN_TRANSIT_TO

Frequently Asked Questions

The protobuf binary format does not include field names - only field numbers and wire types. This tool maps field numbers to GTFS Realtime schema names for all standard fields defined in gtfs-realtime.proto. Unknown fields (custom MTA extensions or fields from newer proto versions) are preserved with their numeric identifiers. You can cross-reference these against the MTA's published .proto extensions.

GTFS Realtime timestamps are POSIX timestamps (seconds since 1970-01-01T00:00:00Z). The decoder outputs the raw integer value. The tool's tree viewer annotates these with human-readable UTC dates when it detects values in the plausible timestamp range (years 2000-2100). The MTA updates feeds approximately every 30 seconds, so arrival predictions degrade quickly if the source file is stale.

Yes. The GTFS Realtime protobuf schema is identical across modes. MTA Bus, Metro-North, LIRR, and Access-A-Ride feeds all use the same FeedMessage envelope. The decoder handles all standard entity types: TripUpdate, VehiclePosition, and Alert. Feed-specific extensions may appear as unresolved numeric field IDs.

The tool accepts files up to 50 MB. Decoding runs in a Web Worker to prevent UI freezing. Typical MTA subway feeds range from 20 KB (single line like L or SIR) to 800 KB (combined 1/2/3/4/5/6 feed during peak hours). The decoded JSON will be substantially larger - expect a 10:1 to 15:1 expansion ratio from binary to formatted JSON text.

The MTA feed often omits departure predictions for terminal stops (since the train does not depart further) and may omit arrival for the origin stop. The GTFS Realtime spec marks both arrival and departure as optional fields. The decoder faithfully represents whatever the binary contains - missing fields simply do not appear in the JSON.

Use curl or wget with your MTA API key: curl -o feed.pb "https://api-endpoint.mta.info/Dataservice/mtagtfsfeeds/nyct%2Fgtfs" -H "x-api-key: YOUR_KEY". The tool decodes the downloaded binary locally. No API key is sent to or stored by this tool. Alternatively, third-party GTFS Realtime archives (e.g., transitfeeds.com) provide historical snapshots.