WS · RFC 6455 Frame Utility

WebSocket Frame Decoder

Decode raw WebSocket frame bytes and inspect FIN, RSV flags, opcode, masking, payload length, masking key, unmasked payload and readable text.

✓ FIN / RSV✓ Opcode✓ Masking ✓ 7 / 16 / 64-bit Length✓ Text Payload✓ Control Frames

WebSocket Frame Decode

● Ready

WebSocket Frame Hex Bytes Paste one complete WebSocket frame beginning with the first frame-header byte. Spaces, commas, colons, hyphens, continuous hex and 0x-prefixed bytes are accepted.

Frame Length Validation Strict mode reports bytes that remain after the declared payload.

Payload Interpretation

Decoder scope: input starts at the WebSocket frame header. HTTP Upgrade request/response headers, TCP/IP headers and TLS records are not part of a WebSocket frame. Client-to-server frames normally use masking; server-to-client frames normally do not.

WebSocket Frame Decode Result Frame Decoded

Decoded Frame —

FIN—

Opcode—

Frame Type—

Masked—

Payload Length—

Header Length—

Masking Key—

Total Frame Size—

Payload —

Frame Header Breakdown —

Validation —

What Is a WebSocket Frame?

After a WebSocket connection is established, application data is transferred as WebSocket frames. Each frame begins with a compact header containing the FIN flag, three reserved bits, a four-bit opcode, a MASK flag and payload-length information.

The header may also contain an extended payload length and a four-byte masking key. The actual application payload follows the header.

WebSocket Frame Header Format

Field	Size	Purpose
FIN	1 bit	Marks the final fragment of a message
RSV1–RSV3	3 bits	Reserved for negotiated extensions
Opcode	4 bits	Identifies continuation, text, binary or control frame
MASK	1 bit	Indicates a four-byte masking key
Payload Length	7 bits	Length value or marker for extended length
Extended Length	0, 2 or 8 bytes	Used for larger payloads
Masking Key	0 or 4 bytes	Used to XOR/unmask the payload
Payload	Variable	Application or control-frame data

WebSocket Text Frame Example

81 05 48 65 6C 6C 6F

81:
FIN = 1
Opcode = 0x1 (Text)

05:
MASK = 0
Payload length = 5

48 65 6C 6C 6F:
"Hello"

WebSocket Masking

Masked frames contain a four-byte masking key immediately before the payload. Each payload byte is XORed with one byte of that key, repeating the key every four bytes.

decoded[i] = encoded[i] XOR mask[i mod 4]

WebSocket clients use masking for frames sent to servers. Frames sent from a server to a client are normally unmasked.

WebSocket Payload Length

Payload lengths from 0 through 125 are stored directly in the second header byte. A value of 126 means that the following two bytes contain a 16-bit unsigned payload length. A value of 127 means that the following eight bytes contain a 64-bit unsigned payload length in network byte order.

WebSocket Opcodes

Opcode	Meaning	Category
0x0	Continuation	Data
0x1	Text	Data
0x2	Binary	Data
0x8	Close	Control
0x9	Ping	Control
0xA	Pong	Control

WebSocket Frame Decoder FAQs

What does 0x81 mean in a WebSocket frame?

0x81 normally represents FIN=1 with opcode 0x1, meaning a final text frame when no RSV bits are set.

What does the MASK bit mean?

MASK indicates whether a four-byte masking key is present and whether the payload bytes must be unmasked using XOR.

Why are WebSocket client frames masked?

The WebSocket framing protocol requires frames sent from clients to servers to be masked.

Can WebSocket messages contain multiple frames?

Yes. A message can be fragmented into an initial text or binary frame followed by continuation frames until a frame with FIN=1 completes the message.

Does this tool decode HTTP WebSocket handshakes?

No. It begins at the binary WebSocket frame header after the HTTP Upgrade handshake has established the WebSocket connection.

What are WebSocket control frames?

Close, Ping and Pong are control frames. Their payloads are limited to 125 bytes and control frames cannot be fragmented.