How to Inspect WebSocket Messages and Frames in Google Chrome DevTools

Modern interactive web applications—including real-time collaborative editors, live financial market trackers, multiplayer browser games, and instant messaging dashboards—rely on WebSockets rather than standard polling HTTP requests. By establishing a persistent, bidirectional TCP connection over a single socket, WebSockets allow servers to push data to clients instantaneously with minimal network overhead.

However, because WebSocket traffic operates as a continuous stream over an established connection rather than discrete request-response cycles, standard network inspection tools often fail to capture individual payloads. Google Chrome DevTools provides a dedicated WebSocket message inspector inside the Network panel that displays incoming and outgoing text, JSON objects, and binary opcode frames in real time. This guide explains how to isolate WebSocket connections, filter message streams, and debug payload structures in Chrome DevTools.

Locating WebSocket Handshakes in the Network Panel

Every WebSocket connection initiates as a standard HTTP GET request featuring an Upgrade: websocket header (known as the WebSocket handshake). Once the remote server responds with HTTP Status 101 Switching Protocols, the connection transitions to the WebSocket protocol (ws:// or secure wss://).

To inspect active connections in Google Chrome:

1. Open Google Chrome and navigate to the web application you wish to inspect.
2. Open Developer Tools by pressing F12 (or Ctrl + Shift + I on Windows/Linux, Cmd + Option + I on macOS).
3. Click on the Network tab along the top DevTools toolbar.
4. In the resource filter bar located directly below the network controls, click the WS (WebSockets) filter pill.
5. Reload the webpage (Ctrl + R or Cmd + R) to capture the initial connection handshake from its initiation.

The Network log will display all active socket endpoints. Secure connections appear with a small padlock icon or a wss:// schema indicator.

Inspecting Live WebSocket Frames and Messages

Once you click on an active WebSocket connection entry in the list, Chrome DevTools opens a secondary inspection pane on the right-hand side:

1. Click on your target WebSocket connection name in the left column.
2. In the right pane, click the Messages tab.
3. DevTools will render a continuous chronological log of every frame transmitted or received across the pipe.

Each entry in the log displays the following critical properties:

• Data Column: The actual message payload content. For human-readable payloads, DevTools displays formatted strings or collapsible JSON trees.
• Direction Indicators:
  • Green Up Arrow (▲): Outgoing message sent from the browser client to the server.
  • Red Down Arrow (▼): Incoming message pushed from the server down to the client.
• Length Column: The payload size in bytes, allowing you to identify bloated payloads that degrade mobile bandwidth.
• Time Column: The precise timestamp down to milliseconds, vital for measuring round-trip messaging latency.

Filtering and Searching Within Message Streams

High-frequency sockets—such as real-time crypto price tickers or multiplayer telemetry feeds—can push hundreds of messages every second, overwhelming the visual log. DevTools offers built-in search and filtering tools to help you isolate specific messages:

1. Text Filter Box: Click inside the Filter input box above the Messages log. Type a specific keyword, user ID, or JSON field name (e.g. heartbeat or order_id) to display only matching frames.
2. Opcode Filtering: Type opcode:1 to filter strictly for text frames, or opcode:2 to inspect binary frames.
3. Clear Stream: Click the circular Clear button (or press the prohibition icon) to wipe previously captured messages from the view without terminating the live connection.

Debugging Binary Payloads (ArrayBuffer and Blob)

Not all WebSocket implementations transmit JSON or plain text. Many high-performance applications send raw binary data formatted as ArrayBuffer, Blob, or Protocol Buffers to maximise throughput.

When binary frames arrive, Chrome DevTools displays the raw byte stream in the Data column alongside its opcode:

• Clicking on a binary frame reveals an integrated Hex viewer and Base64 string decode view.
• You can inspect both the raw hexadecimal values (left column) and the ASCII character interpretations (right column) to reverse-engineer serialisation protocols.

Understanding Common WebSocket Status and Error Codes

Status Code	Code Name	Technical Meaning
1000	Normal Closure	The connection closed gracefully after completing its intended purpose.
1001	Going Away	Endpoint is navigating away (e.g. browser tab closing or server restarting).
1006	Abnormal Closure	Connection dropped unexpectedly without sending a close frame (often TCP timeout or proxy drop).
1009	Message Too Big	Server terminated the connection because a single incoming payload exceeded maximum frame limits.

Troubleshooting WebSocket Inspection in Chrome

• No connections appear under the WS filter: Ensure you opened DevTools before the page initiated the connection. If the socket established prior to launching DevTools, reload the page with DevTools open to capture the upgrade handshake.
• Messages stop appearing after several minutes: Many enterprise firewalls and corporate NAT proxies silently terminate idle TCP streams. Verify whether your client implementation sends regular ping/pong heartbeat frames (typically every 30 seconds) to keep the socket alive.
• Handshake fails with Status 403 or 401: Inspect the Headers tab of the WebSocket entry. Ensure authentication cookies, bearer tokens, or CORS Origin headers match server authorization policies.