All tools

WebSocket Frame Opcode Reference

Network

Look up what a WebSocket frame opcode (0x0 continuation, 0x1 text, 0x2 binary, 0x8 close, 0x9 ping, 0xA pong, plus reserved ranges) means per RFC 6455, or list every defined opcode

Enter a WebSocket frame opcode, the 4-bit field at the start of every frame that says what kind of frame it is, and get back its name, a plain-English description, and whether it's a data or control frame per RFC 6455. The defined opcodes are 0x0 for a continuation frame, 0x1 for text, 0x2 for binary, 0x8 for connection close, 0x9 for ping, and 0xA for pong, with the rest of the 4-bit space reserved for future protocol revisions. This is a distinct lookup from close codes, which live inside the payload of a close frame rather than describing the frame type itself, so this tool answers a different question: what kind of frame is this, not why did the connection end. It's a pure static reference, useful when reading a WebSocket implementation's source or debugging a raw frame dump.

websocketreferencerfc6455protocolnetworking

How to use WebSocket Frame Opcode Reference

  • 1.Enter an opcode from 0 to 15 (0x0 to 0xF), or click one of the examples.
  • 2.Read the frame's name, description, and whether it's classified as a control frame.
  • 3.Browse the full list below to see every opcode in the 4-bit space at once, including the reserved ranges.

Frequently asked questions

How is this different from the WebSocket Close Code Reference?
A close code is a 2-byte value carried inside the payload of a close frame, explaining why the connection ended. An opcode is the frame's own type byte, present on every single frame, saying whether it's text, binary, a ping, a close, and so on. They answer different questions.
What's the difference between a data frame and a control frame?
Data frames (0x0-0x2) carry the actual message payload and can be fragmented across multiple frames. Control frames (0x8-0xA) manage the connection itself, must fit in a single frame, and can't be fragmented, per RFC 6455's framing rules.
What happens if an endpoint receives a reserved opcode?
RFC 6455 requires a compliant endpoint to fail the connection immediately on receiving a frame with an opcode it doesn't understand, since the reserved ranges (0x3-0x7 and 0xB-0xF) have no defined meaning yet.
Does this tool inspect real WebSocket traffic?
No, it's a static reference table. It doesn't open a connection or capture any frames, it just looks up what a given opcode number means.

Use via API, SDK, or MCP

cURL# Free: 1,000 req/day · Pro: 10,000 req/day
curl -X POST https://api.utilix.tech/v1/tools/websocket-opcode-reference \
  -H "Authorization: Bearer utx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"opcode":1}'

Get an API key from your dashboard · Full API docs →

Related tools

WebSocket Close Code Reference / LookupLook up what a WebSocket close code means, per the RFC 6455 close code definitions and the IANA WebSocket Close Code Number Registry's reserved ranges, or browse every well-known codeNetworkEmoji LookupSearch emoji by name or keyword and get back the character, its Unicode code point, and its GitHub-style shortcode.TextHTTP Headers ReferenceSearchable reference for 80+ HTTP request and response headersNetwork