Why must client-to-server frames be masked?

Security. RFC 6455 mandates masking specifically to prevent attacks on infrastructure that proxies WebSocket traffic. Without masking, an attacker who controls partial input bytes (e.g. via cross-origin data) could forge bytes that look like control frames to a transparent proxy, causing it to misinterpret traffic and potentially route data incorrectly. Masking with a random 4-byte key per-frame defeats this. Servers don't need to mask because they aren't the attack target.

What are the opcodes?

0x0 = continuation frame (more of a previous message). 0x1 = text (UTF-8 string). 0x2 = binary. 0x3-0x7 = reserved for non-control. 0x8 = close (with optional code). 0x9 = ping. 0xA = pong. 0xB-0xF = reserved for control. Most app-level traffic is 0x1 or 0x2; control frames (close/ping/pong) handle protocol-level concerns.

How does the variable payload length work?

Three encoding levels for compactness: (1) length 0-125: encoded directly in the 7 bits of byte 1; (2) length 126-65535: byte 1 = 126, then 2 bytes for the length; (3) length 65536+: byte 1 = 127, then 8 bytes for the length (max ~9 quintillion). Most messages use level 1; large file uploads use level 2 or 3.

What's the FIN bit for?

FIN=1 means this is the last (or only) frame of a message. FIN=0 means more frames will continue this message. This allows splitting one logical message across multiple frames (e.g. a large file you don't want to buffer as one big frame). Most simple use cases have FIN=1 always; only when streaming or sending massive payloads does fragmentation matter.

Can I capture frames from Chrome DevTools?

Yes. Open DevTools → Network tab → click your WebSocket connection (look for the WS icon) → click 'Messages' tab. You see decoded text/binary messages, but NOT the raw bytes. To get raw bytes for parsing, use Wireshark on the same network or mitmproxy. For wss:// (TLS), Chrome shows decrypted; Wireshark needs the TLS keys (Chrome's SSLKEYLOGFILE env var enables that).

What about permessage-deflate compression?

It's a WebSocket extension (RFC 7692) where each message gets DEFLATE-compressed before framing. The frame structure stays the same; the payload is the compressed version. This parser doesn't auto-decompress. To handle: parse the frame, then DEFLATE-decompress the payload separately if RSV1 is set (per-message-deflate marker).

Developer Utilities · Free tool

WebSocket Frame Parser

Decode raw WebSocket frame bytes — FIN, opcode, mask, payload length, masking key, and unmasked payload.

Updated June 2026

Frame hex bytes

FIN1 (final fragment)

RSV1 / RSV2 / RSV30 / 0 / 0

Opcode0x1 (text)

MASK1 (client—masked)

Payload length5 bytes (7-bit)

Masking key37 fa 21 3d

Payload (hex)48 65 6c 6c 6f

Payload (text)Hello

Found this useful?Email Buy Me a Coffee

What it does

Paste raw WebSocket frame hex bytes (captured from Wireshark, Chrome DevTools Network tab, or your server logs) and decode the frame structure: FIN flag, RSV bits, opcode (text / binary / close / ping / pong / continuation), MASK flag, payload length (with extended-length encoding for >125 bytes), masking key (if present), and the actual payload — both as hex bytes and decoded UTF-8 if the opcode indicates text.

The WebSocket protocol (RFC 6455, December 2011) defines a binary framing format on top of HTTP for full-duplex client-server communication. After the initial HTTP upgrade handshake, all messages flow as frames following a strict byte layout: byte 0: FIN bit (1=last frame of message), 3 RSV bits, 4-bit opcode; byte 1: MASK bit (1=client-to-server, must be set), 7-bit length encoding; bytes 2-9 (variable): extended length if length 126 or 127; bytes (var)-(var): 4-byte masking key if MASK bit set; remaining bytes: payload (XOR-masked if from client). Server-to-client frames don’t mask; client-to-server frames must.

Common reasons to parse a frame: debugging WebSocket bugs in production logs (why is this connection closing? what was the last frame sent?); verifying mask correctness (one of the most common WebSocket bugs is forgetting to mask client-to-server payloads, which causes server to drop the connection); protocol learning for engineers new to WebSockets; Wireshark export analysis when troubleshooting middleware proxy issues that strip or modify frames.

Embed this tool on your siteShow snippet

Paste this snippet into any page. Loads on-demand (lazy), no tracking scripts, and sized to most dashboards. Replace the height to fit your layout.

<iframe src="https://freetoolarena.com/embed/websocket-frame-parser" width="100%" height="720" frameborder="0" loading="lazy" title="WebSocket Frame Parser" style="border:1px solid #e2e8f0;border-radius:12px;max-width:720px;"></iframe>

Embed docs →

How to use it

Paste hex bytes (with or without spaces, with or without 0x prefix). The parser tolerates common formats: `81 05 48 65 6c 6c 6f`, `0x81 0x05 ...`, `8105 48656c6c6f`.
Read parsed fields: FIN, opcode (with name like 'text frame'), MASK, payload length, masking key (if any), payload bytes.
If opcode is text (0x1), the decoded UTF-8 string appears below the hex payload.
Verify mask correctness: client-to-server frames MUST have MASK=1; server-to-client frames MUST have MASK=0. The parser flags violations.
For multi-frame messages (a single message split across multiple frames), parse each frame separately. The FIN bit indicates the last frame of a message; FIN=0 means continuation expected.

When to use this tool

Debugging WebSocket protocol-level issues that aren't visible at the message API level.
Validating frames captured by Wireshark, mitmproxy, or WSdump.
Teaching / learning the WebSocket framing format.
Reviewing your own WebSocket implementation for spec compliance.

When not to use it

Application-level debugging — most WebSocket bugs are above the framing layer (auth, message format, timing, reconnection logic). For those use Chrome DevTools' WebSocket inspector or your library's debug logs.
Compressed frames (permessage-deflate extension) — those are not handled here. Wireshark can decompress with a plugin; or use a library like ws (Node.js) which handles it natively.
TLS-encrypted WebSocket traffic (wss://) — you can't parse encrypted frames without TLS keys. Capture pre-encryption (Chrome DevTools shows decrypted frames).
Production runtime monitoring — for that use a library that exposes frame stats, not a manual parser.

Common use cases

Pre-decision sanity-check on inputs and outputs
Educational use — demonstrating the underlying concept
Onboarding a colleague who needs the same calculation/conversion
Verifying a number or output before passing it on

Frequently asked questions

Why must client-to-server frames be masked?: Security. RFC 6455 mandates masking specifically to prevent attacks on infrastructure that proxies WebSocket traffic. Without masking, an attacker who controls partial input bytes (e.g. via cross-origin data) could forge bytes that look like control frames to a transparent proxy, causing it to misinterpret traffic and potentially route data incorrectly. Masking with a random 4-byte key per-frame defeats this. Servers don't need to mask because they aren't the attack target.
What are the opcodes?: 0x0 = continuation frame (more of a previous message). 0x1 = text (UTF-8 string). 0x2 = binary. 0x3-0x7 = reserved for non-control. 0x8 = close (with optional code). 0x9 = ping. 0xA = pong. 0xB-0xF = reserved for control. Most app-level traffic is 0x1 or 0x2; control frames (close/ping/pong) handle protocol-level concerns.
How does the variable payload length work?: Three encoding levels for compactness: (1) length 0-125: encoded directly in the 7 bits of byte 1; (2) length 126-65535: byte 1 = 126, then 2 bytes for the length; (3) length 65536+: byte 1 = 127, then 8 bytes for the length (max ~9 quintillion). Most messages use level 1; large file uploads use level 2 or 3.
What's the FIN bit for?: FIN=1 means this is the last (or only) frame of a message. FIN=0 means more frames will continue this message. This allows splitting one logical message across multiple frames (e.g. a large file you don't want to buffer as one big frame). Most simple use cases have FIN=1 always; only when streaming or sending massive payloads does fragmentation matter.
Can I capture frames from Chrome DevTools?: Yes. Open DevTools → Network tab → click your WebSocket connection (look for the WS icon) → click 'Messages' tab. You see decoded text/binary messages, but NOT the raw bytes. To get raw bytes for parsing, use Wireshark on the same network or mitmproxy. For wss:// (TLS), Chrome shows decrypted; Wireshark needs the TLS keys (Chrome's SSLKEYLOGFILE env var enables that).
What about permessage-deflate compression?: It's a WebSocket extension (RFC 7692) where each message gets DEFLATE-compressed before framing. The frame structure stays the same; the payload is the compressed version. This parser doesn't auto-decompress. To handle: parse the frame, then DEFLATE-decompress the payload separately if RSV1 is set (per-message-deflate marker).

Learn more

Explore more developer utilities tools

100% in-browserNo downloadsNo sign-upMalware-freeHow we keep this safe →