Supports-Loading-Mode

The HTTP Supports-Loading-Mode response header signals a document's opt-in to being loaded in higher-risk or novel browsing contexts such as cross-origin prerendering and fenced frames.

Usage

Some browsing contexts carry elevated privacy or security implications. Cross-origin same-site prerendering sends credentialed requests to a page before the user navigates, meaning the server response is fetched and rendered speculatively. Fenced frames embed content in a privacy-isolated container where certain APIs like frame-ancestors in Content-Security-Policy are not honored. Both scenarios require explicit server consent.

The Supports-Loading-Mode header provides the required consent. The server includes one or more tokens in the response, each token representing a loading mode the document supports. The browser checks the header before committing the response to the novel context. If the required token is absent, the browser discards the response and the navigation fails.

The header uses Structured Fields syntax. Multiple tokens appear as a space-separated list. The header only needs to appear in the final response of a redirect chain, since intermediate responses have already completed their network behavior by the time the check runs.

The Speculation Rules API triggers cross-origin same-site prerendering when speculation rules target a URL on a different subdomain of the same site. The browser fetches the page with credentials and only uses the response when credentialed-prerender is present. Same-origin prerendering does not require this header.

Values

credentialed-prerender

The credentialed-prerender token allows the response to be used for a cross-origin, same-site prerender. The browser sends the request with full credentials (Cookies, storage access) and checks for this token before activating the prerendered page. Without the token, the prerender is discarded.

This opt-in exists because cross-origin same-site prerendering exposes the response to a referrer on a different subdomain. Pages serving personalized or authentication-dependent content use this token to confirm awareness of the prerendering context.

fenced-frame

The fenced-frame token allows the response to be loaded inside a <fencedframe> element or an <iframe> embedded within a fenced frame. Without this token, all navigations inside fenced frames fail.

Fenced frames enforce a strong privacy boundary. The embedded document loses access to certain cross-origin communication channels, and headers like CSP frame-ancestors are not enforced in the usual way. The opt-in confirms the server is aware of these constraints.

Requests targeting a fenced frame include Sec-Fetch-Dest: fencedframe, allowing the server to detect the context before responding.

Example

A page opting into cross-origin same-site prerendering. A speculation rule on shop.example.re prerenders deals.example.re, and the response includes the required token.

Supports-Loading-Mode: credentialed-prerender

A page opting into both prerendering and fenced frame loading.

Supports-Loading-Mode: credentialed-prerender
  fenced-frame

An ad creative served inside a fenced frame as part of a Protected Audience auction. The ad server includes the fenced frame token so the browser commits the response.

HTTP/1.1 200 OK
Content-Type: text/html
Supports-Loading-Mode: fenced-frame

Takeaway

The Supports-Loading-Mode header opts a document into novel loading contexts like cross-origin same-site prerendering and fenced frames, requiring explicit server consent before the browser commits the response to these privacy-sensitive environments.

See also

• Prerendering Revamped (WICG)
• Fenced Frame (WICG)
• Navigation Speculation Opt-In (WICG)
• Speculation Rules
• Sec-Purpose
• Sec-Fetch-Dest
• HTTP headers