- Home
- HTTP Headers
- Sec-WebSocket-Accept
Header
Sec-WebSocket-Accept
Learn how the Sec-WebSocket-Accept header indicates server acceptance of a WebSocket connection upgrade. Understand the handshake process and key validation.
TL;DR:
Sec-WebSocket-Acceptis the server’s proof that the WebSocket handshake is real and correctly understood, not just a random HTTP 101 response.
Why This Header Exists
A WebSocket connection begins as an HTTP upgrade request. The browser needs a reliable way to confirm that the server on the other end really understood that upgrade and did not just reply with something that happens to look similar.
That confirmation is Sec-WebSocket-Accept.
What The Exchange Looks Like
The client sends a random Sec-WebSocket-Key. The server transforms it and returns the result:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
If the value is missing or wrong, the browser refuses to open the socket.
Why This Solves A Real Problem
Without this step, a cache, proxy, or generic HTTP server could interfere with the upgrade flow and still return something superficially plausible. The accept value ties the response to the exact client key used for this connection attempt, so stale or fake upgrade responses do not validate.
How The Server Computes It
The algorithm is simple:
- take the client’s
Sec-WebSocket-Key - append
258EAFA5-E914-47DA-95CA-C5AB0DC85B11 - compute SHA-1
- base64-encode the result
Example:
import crypto from 'node:crypto'
function createWebSocketAccept(secWebSocketKey) {
const GUID = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'
return crypto.createHash('sha1').update(secWebSocketKey + GUID).digest('base64')
}
What To Check When Handshakes Fail
If the browser says the WebSocket handshake failed, inspect the whole 101 Switching Protocols response, not just one field.
Common causes:
- the accept value was computed incorrectly
- the client key was altered by whitespace or parsing bugs
UpgradeorConnectionheaders were wrong- the server answered with a normal HTTP response instead of a real WebSocket upgrade
The Useful Mental Model
Sec-WebSocket-Key is the challenge. Sec-WebSocket-Accept is the proof.
That framing makes the whole handshake easier to remember.
Related Headers
Frequently Asked Questions
What is Sec-WebSocket-Accept?
It is the server proof that it received a valid WebSocket upgrade request and knows how to complete the protocol handshake.
How is Sec-WebSocket-Accept calculated?
The server concatenates the client key with the fixed WebSocket GUID, hashes the result with SHA-1, and base64-encodes it.
What happens if Sec-WebSocket-Accept is wrong?
The client rejects the upgrade and the WebSocket connection never opens.
Is the magic GUID secret?
No. The GUID is public. The point is protocol validation, not secrecy.