426 Upgrade Required 4xx

What does 426 mean?

A 426 Upgrade Required response means the server won't process the request using the protocol the client currently used, but indicates (via an Upgrade header) that it would be willing to if the client switches to a different protocol — most commonly, upgrading from plain HTTP to a newer version, or to a different protocol entirely such as WebSocket.

426 is the "you need to upgrade before I'll talk to you this way" counterpart to 101 Switching Protocols (the success response when a protocol upgrade is agreed upon and happens).

How a 426 behaves

• It must include an Upgrade header specifying what protocol(s) the server is willing to switch to
• It can carry a body explaining the requirement, often including human-readable guidance alongside the machine-readable Upgrade header
• It's the rejection counterpart to 101 — where 101 says "yes, let's switch protocols, here we go," 426 says "I won't proceed unless we switch protocols — here's what I'd accept"
• It's most associated with WebSocket and HTTP version negotiation — though TLS-related upgrade requirements (e.g., requiring HTTPS) are more commonly communicated via redirects (301/308) than 426 in practice

Common causes

If you're building the API or website:

• An endpoint specifically requires a WebSocket connection (for real-time features), and a client attempted a plain HTTP request to it instead
• A server is enforcing a minimum HTTP version and rejecting requests using an older version it no longer supports

If you're calling an API:

• You're attempting a regular HTTP request to an endpoint that's specifically designed for WebSocket connections (real-time chat, live updates, streaming data) — the endpoint requires the Upgrade: websocket handshake rather than a standard request/response
• Your client is using an HTTP version the server no longer supports for this endpoint

If you're a website visitor:

• Essentially never encountered directly — protocol upgrades (especially to WebSocket) are handled transparently by browsers for features that need them (live chat widgets, real-time notifications, etc.)

How to fix it

As an API/website builder:

• For WebSocket-only endpoints, ensure the Upgrade header on 426 responses clearly specifies websocket, and document this requirement for API consumers building integrations
• Consider whether a more descriptive error (perhaps including documentation links) alongside the technically-correct 426 would help developers who encounter this while building integrations

As an API consumer:

• If you're getting 426 from an endpoint, check whether it's specifically designed for WebSocket connections — you'll need a WebSocket client/library rather than a standard HTTP request library to interact with it correctly
• Check the Upgrade header in the 426 response for the specific protocol(s) the server expects

As a website visitor:

• Not applicable — protocol upgrades for features like live chat or real-time updates are handled automatically by your browser

426 vs 101

Real-world examples

WebSocket connections begin as an HTTP request with specific Upgrade: websocket and related headers — if a client mistakenly sends a plain HTTP request to a WebSocket-only endpoint (omitting these headers), 426 with Upgrade: websocket is the technically-correct response indicating what the client needs to do differently. Some API gateways and load balancers handle protocol-upgrade requirements transparently for WebSocket traffic, meaning individual application developers may rarely interact with 426 directly even when building real-time features, as the infrastructure layer handles the negotiation.

SEO implications

None — 426 relates to protocol-level negotiation for specific endpoints (often WebSocket) and has no bearing on standard page content delivered via regular HTTP, which search engine crawlers use.

FAQ

What's the difference between 426 and 101?

101 is the success response when a client requests a protocol upgrade and the server agrees — "yes, switching now." 426 is the rejection response when a client didn't request an upgrade but needed to — "I won't proceed without one; here's what I'd accept."

Is 426 specific to WebSocket?

WebSocket is the most common modern context for 426, but the code itself is general-purpose — it can apply to any situation where a server requires a different protocol (including different HTTP versions) than what the client used.

Will I encounter 426 using a standard web browser?

Essentially never directly — browsers handle protocol upgrades (particularly for WebSocket, used by chat widgets, live notifications, etc.) automatically and transparently as part of using features that need them.

How do I fix a 426 when building an integration?

Check the Upgrade header in the response for what protocol is expected, and use an appropriate client library for that protocol (e.g., a WebSocket client rather than a standard HTTP request library) when interacting with that specific endpoint.

Is 426 commonly used for enforcing HTTPS?

Less commonly than you might expect — HTTP-to-HTTPS enforcement is more typically handled via redirects (301/308) to the HTTPS URL, rather than 426. 426 is more associated with application-layer protocol switches like WebSocket than with the HTTP-to-HTTPS transition specifically.

Fun fact

426 and 101 together represent one of HTTP's lesser-known but increasingly relevant capabilities — the ability for a single URL to serve as an entry point into an entirely different protocol (WebSocket being the dominant real-world example), effectively letting HTTP act as a "front door" for real-time, bidirectional communication technologies that operate quite differently from HTTP's traditional request/response model once the upgrade completes.