Skip to main content
Jam captures and displays request and response bodies for network requests, but some payloads contain binary data that can’t be rendered as readable text.

​
How Jam handles binary data

When a request or response body contains binary content (Protocol Buffers, WebSocket binary frames, MessagePack, gRPC payloads, or other non-text formats), Jam displays a placeholder instead of the raw data: 
[binary: 474 bytes]
This tells you:
  • The data is binary: it’s not human-readable text, JSON, or form data.
  • The content length: the number shown is the size of the payload in bytes.

​
Why binary data isn’t displayed as text

Binary formats encode data in compact, non-text representations. Attempting to render them as text would produce garbled, unreadable output. By showing the content length instead, Jam gives you a quick way to identify the payload size without cluttering the DevTools view.

​
Common examples

You’ll typically see [binary: X bytes] for:
  • Protocol Buffers (protobuf): used by many APIs for efficient serialization (e.g., Google services, gRPC)
  • WebSocket binary frames: real-time communication protocols often use binary message types
  • gRPC: built on HTTP/2 and protobuf, payloads are binary by default
  • MessagePack: a binary alternative to JSON
  • Other binary formats: Avro, Thrift, CBOR, or custom binary protocols

​
Debugging tips

  • Use the content length to verify whether the expected amount of data is being sent/received.
  • If you need to inspect the actual binary payload, use your browser’s native DevTools alongside Jam to decode the data with format-specific tools.