## How Jam handles binary data

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.

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.