# WebSocket Frame Parser

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

## URL

https://ilham.dev/tools/websocket-frame-parser/

## 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.

## Features

- Runs in the browser
- No login required

## Input

text input.

## Output

text output.

## Privacy

Processing happens locally in the browser.

No input data is uploaded to ilham.dev.

- Requires login: false
- Requires API key: false
- Stores user data: false


## Examples

- Where do I get the raw frame bytes?
- Why is the payload scrambled?
- What does the opcode mean?
- Does this connect to a server?




## 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 connection is made by this parser, and bytes are decoded in the browser. That does not make production tokens safe to share: the decoded text appears on your screen, and pasted captures may remain in your clipboard or screenshots.