gRPC vs REST: Protobuf vs JSON Payload Race

API Payload Schema

Fields per record 8

Avg. string field length 12 chars

Mobile Network Profile

Gzip / compression

Live Readouts

JSON (REST) payload

— B

Protobuf (gRPC) payload

— B

Transfer time saved by gRPC

—

How it works

Both wires carry the same record — this simulator's own encoder builds the exact byte sequence each format would put on the air, so the sizes below are computed, not guessed.

REST/JSON per field:
  "fieldName":value,   → name bytes + quotes + punctuation

gRPC/Protobuf per field (real wire format):
  tag  = varint((fieldNumber<<3) | wireType)   // 1 byte for field# ≤ 15
  int32  → tag + varint(value)                 // no field name on the wire
  string → tag + varint(byteLength) + UTF-8 bytes
  bool   → tag + 1 byte
  float  → tag + 4 bytes (fixed32)

Protobuf never sends the field name — only a small numeric tag — because the schema (the .proto file) is already known to both client and server. That's the whole size advantage: JSON re-sends "userName_3": as text on every single request.

Transfer time = (bytes × 8) / bandwidth + round-trip latency

Cellular profiles use typical published figures: 2G/EDGE ≈128 kbps / 500 ms, 3G/HSPA ≈2 Mbps / 100 ms, 4G/LTE ≈20 Mbps / 40 ms, 5G ≈100 Mbps / 10 ms. Gzip applies typical measured compression ratios — JSON's repeated text compresses far better (≈65%) than protobuf's already-packed binary (≈15%).

The two lanes below race a physical "packet train" whose length reflects payload size and whose speed reflects the computed transfer time — press Send to watch which one lands first.

JSON / REST train Protobuf / gRPC train

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.