426 Upgrade Required

The server refuses to continue on the current protocol and requires the client to switch to a different one to proceed.

Defined in RFC 9110 §15.5.22

What 426 means

RFC 9110 defines 426 for a server that will not process the request over the protocol currently in use but might if the client switches. The server communicates which protocol it requires via the Upgrade response header, listing one or more acceptable protocols the client can switch to, such as a newer HTTP version or TLS.

In practice 426 is used to push a plaintext HTTP/1.1 client onto TLS, to require a WebSocket upgrade on an endpoint that only makes sense as a WebSocket, or occasionally to enforce a minimum HTTP version. It is spec-correct for signaling an in-place protocol switch on the same connection, which makes it distinct from a simple redirect to a different URL such as 301 or 308 to an https:// location.

WebSocket handshakes rely directly on this mechanism: a client sends Connection: Upgrade and Upgrade: websocket to request the switch, and a server can respond with 426 if a client hits a WebSocket-only endpoint over plain HTTP without those headers, telling it exactly what upgrade is required to proceed.

Common causes

A client connects over plain HTTP/1.1 to an endpoint that requires TLS, and the server returns 426 instead of redirecting.
A client requests a WebSocket-only endpoint without sending the Connection and Upgrade headers needed to negotiate the switch.
The server enforces a minimum HTTP version, such as HTTP/2, that the client's connection does not meet.
A legacy client or bot uses an outdated protocol version that the server has since deprecated.

How to fix a 426

If you are the client (browser user or API caller)

Reissue the request using the protocol named in the response's Upgrade header, such as switching to HTTPS or sending proper WebSocket upgrade headers.
Update the HTTP client library to one that supports the protocol version the server requires.
Include Connection: Upgrade and Upgrade: <protocol> headers when deliberately initiating a protocol switch.

If you run the server

Set the Upgrade response header explicitly so the client knows exactly which protocol or protocols are acceptable.
Prefer a straightforward 301 or 308 redirect to https:// over 426 when the only goal is forcing HTTPS, since it is more universally understood by clients.
Implement the Upgrade handshake correctly for WebSocket or HTTP/2 endpoints so compliant clients can switch seamlessly on the first try.

Example

GET /chat HTTP/1.1
Host: realtime.example.com
Connection: keep-alive

HTTP/1.1 426 Upgrade Required
Upgrade: websocket
Connection: Upgrade
Content-Type: text/plain

This endpoint requires a WebSocket upgrade to proceed.

The client hit a WebSocket-only endpoint without requesting the upgrade, so the server names the required protocol.

Try it live

Our free status responder returns a real HTTP 426 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/426