101 Switching Protocols 1xx

What does 101 mean?

A 101 Switching Protocols response means the server agrees to a client's request (via the Upgrade header) to switch from the current protocol to a different one — and after this response, the underlying connection continues using the new protocol instead of HTTP. It's the success counterpart to 426 (Upgrade Required): where 426 says "I won't proceed unless we switch protocols," 101 says "yes, let's switch — starting now."

By far the most common real-world use of 101 is establishing a WebSocket connection — a request begins as HTTP with Upgrade: websocket and related headers, the server responds with 101, and from that point on, the connection operates as a WebSocket connection rather than a normal HTTP request/response cycle.

How a 101 behaves

• It includes an Upgrade header confirming what protocol the connection is switching to
• After this response, the connection is no longer "HTTP" in the usual sense — for WebSocket, this means the connection becomes a persistent, bidirectional channel rather than a series of discrete request/response exchanges
• It's an interim/informational response (1xx), but unlike 100, it represents a more fundamental transition — the rest of the "conversation" on this connection happens in an entirely different protocol
• It's specific to the connection it occurs on — other requests to the same server (on different connections) are unaffected and continue using HTTP normally

Common scenarios

If you're building the API or website:

• You're implementing a WebSocket endpoint for real-time features (chat, live notifications, collaborative editing, live data feeds) — the WebSocket handshake involves your server responding with 101 to establish the connection
• Many web frameworks and libraries handle the 101 handshake automatically when you set up a WebSocket route/handler, abstracting away the raw HTTP-to-WebSocket transition

If you're calling an API:

• You're connecting to a WebSocket endpoint using a WebSocket client library, which handles the 101 handshake internally — establishing the connection, then giving you a WebSocket interface (send/receive messages) rather than HTTP request/response semantics

If you're a website visitor:

• Every time a website's chat widget, live notification system, or real-time dashboard connects, a 101 handshake likely happened behind the scenes to establish that real-time connection — entirely invisible during normal use

Real-world examples

Real-time features across the web — chat applications, collaborative editing tools, live sports score updates, financial trading platforms with live price feeds — virtually all rely on WebSocket connections established via the 101 handshake, making it one of the most operationally important status codes for modern interactive web applications, despite being almost never directly visible to either developers or users in normal operation. Browser developer tools' Network tab will typically show a WebSocket connection's initial 101 handshake if you inspect network activity while a real-time feature is active, one of the few contexts where this status code becomes visible.

SEO implications

None — 101 represents a protocol transition for specific connections (typically WebSocket) and has no relevance to standard HTTP page content delivered to crawlers.

FAQ

What's the difference between 101 and 426?

426 is a rejection — "I won't process this request unless you switch protocols, here's what I'd accept." 101 is an acceptance — "yes, switching to the protocol you requested, starting now."

Is 101 the same thing as a WebSocket connection?

101 is specifically the handshake response that establishes a WebSocket connection — after 101, the connection operates as WebSocket. So 101 is the transition point, not the ongoing WebSocket communication itself (which uses its own framing, not HTTP).

Will I see 101 if I just browse a website normally?

Generally not directly, though many modern websites use WebSocket connections behind the scenes for live features — these connections begin with a 101 handshake that's invisible in normal browsing but visible in browser developer tools' network inspection.

Can a connection switch back from WebSocket to HTTP after 101?

No — once a connection has switched protocols via 101, it continues operating as the new protocol (e.g., WebSocket) for the lifetime of that connection. A new HTTP request would require a separate connection (or, in the case of WebSocket, the WebSocket connection itself supports its own message-based communication going forward).

Do I need to implement 101 handling manually for WebSocket features?

Typically no — most web frameworks and WebSocket libraries handle the 101 handshake as part of their WebSocket connection-handling abstractions, so application developers usually work with higher-level "connection," "message," and "close" events rather than raw HTTP status codes.

Fun fact

101 represents one of the most consequential "small" status codes in this entire reference — a single 101 response is the gateway through which an enormous amount of real-time web functionality operates, yet it remains one of the least-discussed codes precisely because, once it does its job, the connection stops being "HTTP" in any way that the status-code framework continues to describe.