WebSocket Frame Decoder (RFC 6455)

What is a WebSocket frame?

Every message sent over a WebSocket connection is wrapped in a frame — a small binary header (defined by RFC 6455 §5.2) followed by the payload data. The header packs several fields into its first byte or two: a FIN bit, three RSV (reserved) bits, a 4-bit opcode identifying the frame type (text, binary, ping, pong, close…), a MASK bit, and a payload length that can itself take three different byte-widths depending on how big the payload is. If the frame is masked, the payload is also XORed against a 4-byte masking key before you can read it. None of that is readable by eye — this tool decodes it field by field.

How to use it

1. Paste the raw frame bytes as hex (space, colon, or 0x-separated — 81 05 48 65 6c 6c 6f and 0x81,0x05,0x48,0x65,0x6c,0x6c,0x6f both work) or as a binary bit string (e.g. 10000001 00000101 ...).
2. Frame Fields shows FIN, RSV1–3, the opcode (with its name), MASK, both the raw 7-bit length field and the actual resolved payload length, the masking key (if any), and any protocol warnings.
3. Byte Structure breaks the frame down by byte offset — which bytes make up the header, the extended length (if present), the masking key (if present), and the payload — mirroring the layout in the RFC 6455 diagram.
4. Payload shows the payload as received (still masked, if applicable), the XOR-unmasked hex, and — for text frames — the decoded UTF-8 text. Close frames get their 2-byte status code and UTF-8 reason phrase split out separately.
5. JSON Export gives the same decoded fields as a single JSON object for scripting or bug reports.

The three payload-length forms

The second byte's low 7 bits encode the length, but which meaning they carry depends on the value:

• 0–125 — that's the actual payload length.
• 126 — the real length follows as the next 2 bytes (big-endian, unsigned 16-bit).
• 127 — the real length follows as the next 8 bytes (big-endian, unsigned 64-bit; the top bit must be 0 per the RFC).

Masking

Client-to-server frames must be masked (MASK=1) — the payload is XORed byte-by-byte against a 4-byte masking key that immediately follows the length field, cycling the key every 4 bytes (payload[i] XOR key[i mod 4]). Server-to-client frames are normally unmasked. This tool unmasks automatically whenever MASK=1 and shows both the raw and unmasked hex so you can compare.

What this tool flags as a warning

• A control frame (close/ping/pong, opcode 0x8–0xA) with FIN=0, or with a payload over 125 bytes — both are invalid per RFC 6455 §5.5 (control frames can't be fragmented or carry large payloads).
• Any RSV bit set without a negotiated extension to define it.
• A reserved opcode (0x3–0x7 or 0xB–0xF) — undefined without an extension.
• A truncated frame — declared length exceeds the bytes actually provided.

What this tool does not do

It decodes a single already-captured frame's header — it doesn't open a live WebSocket connection, doesn't reassemble a sequence of fragmented frames (opcode 0x0 continuation frames) into one logical message, and doesn't validate the HTTP Upgrade handshake that precedes any WebSocket traffic.

FAQ

Where do I get raw frame bytes to paste in? Capture them from your browser's DevTools Network panel (WS tab → click a frame → raw bytes), from a packet capture (Wireshark's "Follow → WebSocket Stream" or a hex view of the TCP payload), or from a proxy tool like Burp/mitmproxy.

Why does my input fail to parse? A frame header is at least 2 bytes — make sure you've pasted the full frame, not just the payload. Hex input needs an even number of hex digits; binary input needs a bit count that's a multiple of 8.

Is my data uploaded anywhere? No — decoding runs entirely in your browser. Nothing you paste ever leaves your device.

Related tools

• Hex Dump Viewer — for a general-purpose byte-level view of any binary blob.
• HTTP Header Analyzer — decode the HTTP Upgrade handshake that precedes a WebSocket connection.
• Raw HTTP Request Parser — parse the raw HTTP request line and headers.