Upgrade-Insecure-Requests

The HTTP Upgrade-Insecure-Requests request header signals the server the client prefers encrypted responses and supports automatic upgrading of insecure resource URLs.

Table of Contents

Usage

The Upgrade-Insecure-Requests header is defined in the Upgrade Insecure Requests specification. When a browser sends this header with a value of 1, the browser is telling the server two things: the browser supports the upgrade-insecure-requests Content-Security-Policy directive, and the browser actively prefers an HTTPS response.

On the server side, receiving this header means the server is safe to redirect the client to a secure version of the resource. The server responds with a Content-Security-Policy header containing the upgrade-insecure-requests directive, which instructs the browser to rewrite all insecure (HTTP) URLs on the page to their HTTPS equivalents before fetching them. This covers images, scripts, stylesheets, and other subresources.

The upgrade mechanism addresses mixed content on sites migrating to HTTPS. Rather than updating every hardcoded HTTP URL in a page's source, the CSP directive handles the rewriting at the browser level, preventing mixed-content warnings and blocked resources.

Values

The header carries a single value:

1

The value 1 indicates the client supports and prefers insecure request upgrading. No other values are defined. The absence of the header means the client has not expressed a preference.

Example

A browser requesting a page and signaling support for insecure request upgrading:

GET /page HTTP/1.1
Host: example.re
Upgrade-Insecure-Requests: 1

The server responding with a redirect to the secure version and the CSP directive instructing the browser to upgrade all subresource URLs:

HTTP/1.1 307 Temporary Redirect
Location: https://example.re/page
Content-Security-Policy: upgrade-insecure-requests
Vary: Upgrade-Insecure-Requests

Takeaway

The Upgrade-Insecure-Requests header enables browsers and servers to cooperate on migrating page loads to HTTPS, automatically rewriting insecure subresource URLs through the Content-Security-Policy upgrade-insecure-requests directive.

See also

Last updated: March 11, 2026