Upgrade-Insecure-Requests

Sites migrating to HTTPS often have hardcoded HTTP URLs embedded in page sources. The Upgrade-Insecure-Requests request header signals the server that the client supports automatic upgrading of insecure resource URLs to their HTTPS equivalents.

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

Two mechanisms sharing a name

The request header and the CSP directive travel in opposite directions and get conflated constantly. Browsers send Upgrade-Insecure-Requests: 1 on navigation requests, announcing the client understands upgrade redirects. Servers answer with the upgrade-insecure-requests directive inside Content-Security-Policy, instructing the browser to rewrite plain-HTTP subresource addresses to HTTPS before fetching.

Observed browser behavior is broader than most descriptions: the header travels on HTTPS navigations too, and on iframe navigations, not only on plain-HTTP top-level requests, while staying off subresource fetches. Responses branching on the header deserve Vary: Upgrade-Insecure-Requests so caches keep the variants apart.

The directive is among the most deployed pieces of CSP, with Web Almanac measurements showing a policy consisting of nothing else on roughly a fifth of observed CSP headers. The request header keeps shipping in every engine, while automatic HTTPS upgrading in Chromium covers much of the same ground.

See also

Last updated: August 17, 2026