# WebSocket Frame Parser Guide

Decode a raw WebSocket frame from hex and explain its opcode, length and payload.

- Tool: https://ilham.dev/tools/websocket-frame-parser/
- Guide URL: https://ilham.dev/guides/websocket-frame-parser/
- Tool guides index: https://ilham.dev/guides/tools/
- Broader guide: Testing and Debugging WebSockets (https://ilham.dev/guides/websocket-debugging/)

## What it does

Paste the hex bytes of a single WebSocket frame and the page decodes the bits the RFC defines: FIN, the reserved bits, the opcode, whether the frame is masked, the payload length, the masking key and the payload itself. Text frames are unmasked and shown as readable text.

## Use the tool

Open https://ilham.dev/tools/websocket-frame-parser/, add the input the tool asks for, run it, and check the output before using it elsewhere.

## Input and output

- Input: text.
- Output: text.
- Category: Network.

## Privacy and processing
Processing happens locally in your browser. This tool does not upload the input to ilham.dev.

## Questions

### Where do I get the raw frame bytes?

From a packet capture or a proxy that logs frames, such as Wireshark with a WebSocket filter, or from a test that dumps the bytes your client sent. Copy the frame payload bytes, not the TCP or TLS wrapper, and paste them as hex.

### Why is the payload scrambled?

Client-to-server frames are masked, so the bytes on the wire are XORed with a four-byte key. The parser applies that key to recover the payload. A server-to-client frame is not masked and is shown as it arrived.

### What does the opcode mean?

0x1 is text, 0x2 is binary, 0x0 continues a fragmented message, 0x8 closes the connection, 0x9 is a ping and 0xa is a pong. Anything else is reserved and is labelled as such rather than guessed at.

### Does this connect to a server?

No. It reads bytes you paste and nothing else. There is no socket and no request, so it is safe for frames that contain tokens or message payloads from production.