HTTP 426 Upgrade Required

HTTP 426 Upgrade Required means the server will not process the request using the current protocol and requires the client to switch to a different protocol specified in the Upgrade response header. The client must re-issue the request using the upgraded protocol.

Quick reference

Code	426
Name	Upgrade Required
Category	4xx Client Errors
Specification	RFC 9110 §15.5.22
IANA status	Assigned
Required response header	`Upgrade: [protocol]` — specifies which protocol to switch to
Client behavior	Re-issue the request using the protocol specified in the Upgrade header.
In-depth guide	HTTP 426 protocol upgrade guide →

What it means

RFC 9110 requires that a 426 response include an Upgrade header listing the protocol(s) the server is willing to accept. Without this header, the client cannot know what to upgrade to and the response is not actionable.

The most common real-world use is WebSocket upgrade enforcement and TLS enforcement on servers that serve both HTTP and HTTPS. A server that strictly requires HTTPS can return 426 instead of a redirect, explicitly signaling that the protocol (not just the scheme or port) must change. In practice, most servers return 301 or 308 to redirect HTTP to HTTPS rather than 426, but 426 is the more semantically precise response when the issue is the transport protocol itself.

426 vs HTTPS redirects

Using 426 for HTTP-to-HTTPS enforcement is semantically correct but uncommon. A 301 or 308 redirect to the HTTPS URL is more practical because clients follow the redirect automatically. With 426, the client must read the Upgrade header, understand the upgrade requirement, and construct a new request — a capability that not all clients implement. For HTTPS enforcement, prefer 301 or 308 redirects with HSTS headers rather than 426.

Common causes

WebSocket upgrade enforcement

WebSocket connections begin as HTTP requests with an Upgrade: websocket request header. If the server requires WebSocket and receives a plain HTTP request without the upgrade header, it may return 426 with Upgrade: websocket to signal the requirement. This is most commonly seen when a client accesses a WebSocket endpoint with a regular HTTP client.

HTTP/2 or HTTP/3 enforcement

Servers that require HTTP/2 can return 426 with Upgrade: h2 or Upgrade: h2c (HTTP/2 over cleartext) for clients using HTTP/1.1. In practice this is rare because HTTP/2 negotiation happens at the TLS layer (via ALPN) rather than via application-level 426 responses.

Custom application protocol enforcement

Application servers using HTTP as a carrier for custom protocols (multiplexed streams, binary protocols layered over HTTP) may return 426 when a client connects using standard HTTP without negotiating the custom protocol.

How to handle 426

Read the Upgrade header in the 426 response to identify the required protocol.
Re-issue the request using the specified protocol. For WebSocket upgrades: send an HTTP Upgrade request with the correct headers. For HTTPS: switch to TLS. For HTTP/2: negotiate via ALPN during TLS handshake.
If you control the server and are using 426 for HTTPS enforcement: consider switching to 301/308 redirects with HSTS for better client compatibility.

426 vs 505 vs 400

Code	Meaning
426	Server requires client to use a different protocol — upgrade to what Upgrade header specifies
505	Server does not support the HTTP version used in the request
400	Request is malformed — not a protocol version issue

Related resources

On this site: HTTP 426 protocol upgrade guide · HTTP 425 Too Early · HTTP 505 HTTP Version Not Supported · All 4xx client errors

Comparisons: 426 vs 505

Standards: RFC 9110 §15.5.22 · IANA Registry · MDN Web Docs: 426