Protobuf's binary encoding is compact as a consequence of being schema-driven: with field names and structure defined up front, payloads carry only the data. This page looks at how much space that saves, and when it doesn't.
Edit the JSON below or load an example to see the wire size change.
--
size vs JSON
Payload Input
Where the binary encoding saves its bytes
Size vs. Compression
JSON's repeated keys compress well, so gzip wins back much of what the binary encoding saves by dropping field names. Compression isn't free either: it costs CPU on both ends, and on small payloads its framing can exceed what it saves. Measure both with your own data.
The binary encoding shines on numbers, enums, and messages that leave most fields unset, and gains least on long strings. When the payload needs to be human-readable, Protobuf serializes to JSON too: ProtoJSON is part of the specification, so one schema and one set of generated types produce either encoding.
Performance in Practice
Parse cost depends on the language and the library. In C++, Go, and Java the binary encoding can parse much faster than JSON; in JavaScript and Python the gap narrows, since the data still has to cross into the runtime. Benchmark your own services before treating generic numbers as architecture guidance.
These write-ups benchmark the difference in practice:
Auth0 Engineering
Classic comparison of binary vs text overhead in real-world API requests.
Official gRPC Benchmarks
Throughput and latency metrics for Protobuf-over-HTTP/2 across various languages.
Atlassian Engineering
A case study on cutting p99 latency by 20% and CPU usage by 75% with Protobuf.
hyperpb
A dynamic parser for Go that works from descriptors instead of generated code, benchmarked against the standard runtime.
Next
Binary
The wire format field by field: tags, varints, length prefixes, and how each type is laid out in bytes.