Skip to main content

Documentation Index

Fetch the complete documentation index at: https://jam.dev/docs/llms.txt

Use this file to discover all available pages before exploring further.

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.