protobuf.com

Efficiency

Efficiency

A Protobuf schema already defines the field names and the structure, so the binary encoding doesn't repeat any of that on the wire. It just carries the data. Size is not the reason most teams pick Protobuf, the schema is what does the real work there, but the smaller payload is a genuine side effect and worth measuring. This page looks at how much space it saves, and where it doesn't.

Edit the JSON below or load an example to see the wire size change.

Size comparison
This weighs minified JSON against the Protobuf binary encoding, PB, for the same message, both generated from the schema. Pick a Content-Encoding to see how much of that gap survives compression.
Uncompressed
—
json
—
pb

--

size vs JSON

Payload Input

Data input (JSON)
{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "name": "Hiro Protagonist",
  "email": "hiro@metaverse.com",
  "age": 24,
  "heightCm": 175.5,
  "weightKg": 70.2,
  "role": 2,
  "birthDate": {
    "year": 1992,
    "month": 5,
    "day": 22
  }
}

Where the binary encoding saves its bytes

Numeric Tags

Field names aren't sent, only the small numeric tags from the schema.

No Syntax Overhead

Structure comes from the schema, so no braces, quotes, or commas are sent.

Varints

Small integers take 1-2 bytes, not their full width.

Unset Fields

A field that isn't set takes exactly zero space in the payload.

Size vs. Compression

JSON's repeated keys compress well, so gzip wins back a lot 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 the framing it adds can exceed what it saves. Measure both with your own data.

The binary encoding does best on numbers, enums, and messages that leave most fields unset. It gains the least on long strings. When you need the payload to be human-readable, Protobuf messages serialize to JSON too. ProtoJSON is part of the specification, so the same schema and the same generated types produce either encoding.

Performance in Practice

Speed comes out of the same schema-driven design, and on its own it is not much of a reason to adopt Protobuf. Parse cost still 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 either way. Benchmark your own services before treating generic numbers as architecture guidance.

A few write-ups measure that 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

How the wire format works, field by field. Tags, varints, length prefixes, and how each type is laid out in bytes.

Previous
Validation
Next
Binary