Actually, both formats are bad and it is an insult to human intelligence that they are still so widespread in 2026.
JSON has still the excuse of design simplicity, Protobuf does not even has that for itself.
Makes sense. JSON has far more repeated/predictable bytes because every item duplicates the same keys, which is exactly the kind of redundancy LZ77-family compressors do well.
Protobuf actually has less per field overhead on the wire, that's why it's smaller uncompressed in the first place.
The remaining time gap depends on the data itself. Lots of unique high-entropy values (UUIDs, floats, random strings) and protobuf still wins compressed. Lots of repeated structure with small values and JSON closes the gap or beats it.
Protobuf strips redundancy at encoding time, gzip strips redundancy at compression time. JSON leaves the redundancy in and lets gzip do the work. So you're trading CPU (compress/decompress on every hop) for a payload that started bloated vs. protobuf which is already close to the information-theoretic floor, especially as item count grows.