Why are client-to-server WebSocket frames masked?

RFC 6455 requires masking to prevent cache poisoning attacks against intermediary web proxies. This tool decodes the 4-byte key and unmasks the payload.

Can I inspect WebSocket close status codes?

Yes. It decodes standard RFC 6455 closure codes (e.g. 1000 Normal, 1001 Going Away, 1006 Abnormal) and parses close reason text.

WebSocket Frame Inspector & RFC 6455 Decoder

Debug raw binary WebSocket packets offline. Inspect header bits (FIN, RSV1-3, Opcode, MASK), automatically unmask client-to-server frames using the 4-byte masking key, and decode UTF-8 text or binary payloads.

Opcode -

FIN Flag -

Masked -

Payload Size 0 B

RAW FRAME (HEX DUMP OR HEX STREAM) 0 bytes

RFC 6455 HEADER ANALYSIS & UNMASKED PAYLOAD Ready

Frequently Asked Questions

Why do client WebSocket frames have a 4-byte mask?

RFC 6455 requires all client-to-server WebSocket frames to be masked using a random 32-bit key. This prevents cache poisoning attacks on intermediary web proxies that might mistake WebSocket payloads for HTTP requests.

How is the WebSocket payload unmasked?

Each payload octet i is transformed with the XOR operator: unmasked[i] = masked[i] XOR masking_key[i % 4].

Is my network frame sent to any server?

No. Parsing and XOR unmasking are executed entirely client-side inside your browser via local JavaScript typed arrays.