Frame fields
03FIN, opcode, mask state, length, and optional masking key let the receiver interpret one frame.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 5.2 ↗
RFC 6455 · § 5.2EXAMPLE
3 / 3
03
Interpret the frame content.
In this illustrated client text frame, unmask five bytes to recover Hello.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
Read the updated RFC section ↗
Read control fields before interpreting the payload.
- FIN marks the final fragment; opcode identifies continuation, text, binary, or a control frame. Reserved bits are zero unless an extension defines them.
- Payload lengths 0–125 fit directly; 126 and 127 introduce extended-length fields. The high bit of a 64-bit length must be zero.
- Client-to-server frames set MASK and carry a 32-bit masking key; server-to-client frames are not masked.
A single message can span multiple frames. Payload length includes extension data when extensions add it; implementations should impose appropriate resource limits.
Read the RFC section ↗Diagrams simplify the RFC. Read the linked sections for complete requirements.
Privacy