Protocols / Binary serialization
Paste hexadecimal bytes starting at a frame header. Try the masked, fragmented or truncated examples.
Start at a frame header: 81 05 48 65 6c 6c 6f. Hex pairs; whitespace, commas or colons; 0x per byte.
Enter frame bytes or choose an example.
Everything runs in this browser tab. Inputs are not sent or saved.
Enter frame bytes or choose an example.
A log can contain several frames even when an application reports one message. This WebSocket frame decoder keeps each boundary visible, so a ping between two fragments does not look like part of the text. Compare the byte offset with your capture to find where the next header really begins.
Use the WebSocket hex decoder on bytes captured after the HTTP upgrade. Browser message events normally contain application data with the framing already removed. Start with a known frame header; interpreting a TCP packet or a plain message as a frame gives misleading results.
The WebSocket frame decoder advances by the actual header and payload lengths instead of stopping at the first frame. Each card keeps its absolute offset. If a later frame is truncated, earlier complete frames stay visible and report export is disabled until the input is complete.
A WebSocket masking key contains four bytes and repeats across the payload. The view shows the bytes on the wire beside their XOR result. A different key starts again at each frame; changing the mask does not change the payload length.
The direction option checks whether MASK matches a client or server sender. Leaving it unspecified skips only that check; it does not split an interleaved conversation. Include frames from the same direction and retain their original order.
Each payload preview stops at 256 bytes. That is a display limit, whereas a truncated frame means the input contains fewer bytes than the header declares. The status and error location distinguish the two; only a complete parse can be exported.
Automatic parsing waits 350 ms after an edit. Switch it off to reveal Parse frames and use Ctrl/Cmd+Enter. Editing bytes or direction immediately disables export. Example and Clear first show a replacement preview; Undo restores both input and result.
The WebSocket frame parser reads the 7-bit value and the 16- or 64-bit extended length in network byte order. Large declarations are checked as exact integers before allocation. Non-minimal length encodings remain visible with a protocol warning.
Close, ping and pong are separate frame types. Close payloads expose the two-byte status and UTF-8 reason, while invalid control lengths, FIN values or close codes are flagged. An observed close frame does not prove that the connection closed cleanly.
Standalone text frames use strict UTF-8. Binary payloads may have a readable preview without becoming text messages. A code point cut by the display limit is withheld, while invalid complete text receives a warning. Fragment and extension payloads are not presented as complete text.
Incomplete headers, extended lengths, masking keys and payloads stop parsing at an explicit byte offset and source line and column. The view preserves earlier complete frames. Unknown opcodes and RSV flags instead remain inspectable warnings because their byte boundaries are still known.
Client frames carry a four-byte key so their wire bytes cannot be chosen freely in ways that confuse intermediaries. The same repeating XOR operation removes that mask. It provides no secrecy: anyone with the frame has the key. Server frames are unmasked under the base protocol.
126 and 127 are markers, not literal payload sizes. They select the next two or eight bytes as an unsigned, big-endian length. The 64-bit form must have its top bit clear. WebSocket payload length excludes the header and the optional four-byte masking key.
Yes. Paste concatenated frames from one direction in wire order. The parser advances by each declared length and lists every complete frame, including empty payloads and intervening controls. If a frame is incomplete, fix the capture before exporting the report.
An empty close payload has no status code. Otherwise the first two bytes hold the code and the remaining bytes hold a UTF-8 reason. A one-byte payload, forbidden code or invalid reason is flagged. The page reports the value rather than inventing a reason for an empty close frame.
No. HTTP Upgrade requests and responses belong to the handshake, before this frame format begins. Extract the subsequent WebSocket bytes first. The tool cannot remove TCP/IP or TLS framing, establish a connection or validate the server handshake.
Found a calculation or validation issue?
Use the WebSocket frame decoder to compare offsets, inspect the masking key and isolate the first incomplete frame before changing your application parser.