What strict-origin-when-cross-origin means

What strict-origin-when-cross-origin sends

Referrer-Policy only decides what goes into the Referer request header and document.referrer. It never blocks a request and never causes a CORS error. Chrome DevTools shows Referrer Policy: strict-origin-when-cross-origin under General in the Headers tab for every request without another policy, which is why it sits next to failed requests too.

The W3C Referrer Policy spec makes strict-origin-when-cross-origin the default. A same-origin request sends the full URL without the fragment, a cross-origin request sends only the origin, and a request from HTTPS to plain HTTP sends nothing. A referrer longer than 4,096 characters is cut to the origin.

The test on 28 October 2026 loaded https://shop.example/checkout?order=123#pay with no policy set in Chromium 153, Firefox 155 and WebKit 26.6 (Playwright 1.63; WebKit is Playwright's Linux build) and sent cross-origin requests to the echo service https://httpbin.org/headers. new Request('/x').referrerPolicy was the empty string in all 3, which means the document's policy applies.

The default since Chrome 85, Firefox 87 and Safari 15

MDN's browser compatibility data (version 8.1.7) dates the default to Chrome 85, Firefox 87 and Safari 15; the Referrer-Policy header itself works since Chrome 56, Firefox 50 and Safari 11.1. The previous default, no-referrer-when-downgrade, sent the full URL, query string included, to every HTTPS site.

The same data marks the relaxed values unsafe-url, no-referrer-when-downgrade and origin-when-cross-origin as removed in Firefox 92 and Safari 13. In the test, a cross-site fetch() with referrerPolicy: 'unsafe-url' sent the full URL from Chromium only. Firefox and WebKit sent the origin, and Firefox logged Referrer Policy: Ignoring the less restricted referrer policy "unsafe-url" for the cross-site request: https://httpbin.org/headers (Firefox prints curly quotes).

Find the real error behind a failed request

1. Read the Console

   the red line for the request names the actual reason, such as a CORS check, mixed content or a network error.

2. Read the Status column

   in the Network panel, the Status of the failed row is what matters, not the Referrer Policy line under Headers.

What Chrome's Status column shows, and where to go next:

• CORS error: the response lacked an acceptable Access-Control-Allow-Origin; see Access to fetch blocked by CORS policy.
• (blocked:mixed-content): an HTTPS page requested an http:// URL; see mixed content.
• (blocked:csp): the page's Content-Security-Policy blocked the request.
• (failed) with a net::ERR_ code: DNS, TLS or connection trouble; see TypeError: Failed to fetch.
• (canceled): the request was aborted, for example by a navigation or an AbortController.
• A number such as 429: the server answered with an error; see 429 Too Many Requests.

If the cause is a missing CORS header on an API you don't control, https://proxy.cors.dev/ followed by the full URL adds it, with no signup, GET and HEAD only and about 600 requests a minute per IP.

When the Referer matters: referrer-restricted keys

Some services lock API keys to referring sites. Google Maps Platform keys with website restrictions are the common case, and Google's docs reserve IP-address restrictions for server-side web services, so browser code needs the referrer kind. When the Referer doesn't match, or is missing, the Maps JavaScript API fails with RefererNotAllowedMapError: "The current URL loading the Maps JavaScript API has not been added to the list of allowed referrers."

Google's Maps Embed docs warn that a page with a referrer meta tag of no-referrer or same-origin sends no Referer, which "may cause your API key restriction to reject the requests". They recommend referrerpolicy="strict-origin-when-cross-origin", which "Sends only your base domain (e.g., https://example.com/) to Google".

No proxy can pass the browser's Referer on. JavaScript can't set the Referer header, the free cors.dev proxy forwards only Accept, Accept-Language, If-None-Match, If-Modified-Since and Range, and cors.dev Pro drops browser identity headers such as Referer and Origin. An echo service behind proxy.cors.dev received neither in the test. Call referrer-checked APIs straight from the page.

Change the policy for a page or a request

• The Referrer-Policy response header sets the policy for the whole page.
• <meta name="referrer" content="strict-origin-when-cross-origin"> in the <head> does the same from HTML.
• A referrerpolicy attribute works on a, img, iframe, script and link elements.
• The referrerPolicy option of fetch() sets it for one request.

Stricter values such as no-referrer and same-origin hide even your origin from other sites, which breaks referrer-restricted keys. Looser values such as unsafe-url leak paths and query strings, which can hold tokens or order numbers, wherever the browser still honours them. The snippet asks https://httpbin.org/headers which Referer arrived under the default, then with no-referrer and unsafe-url.

async function refererSentTo(url, init) {
  const response = await fetch(url, init);
  const { headers } = await response.json();
  return headers.Referer ?? '(none)';
}

const echo = 'https://httpbin.org/headers';

// On https://shop.example/checkout?order=123 this logs https://shop.example/
console.log(await refererSentTo(echo));

console.log(await refererSentTo(echo, { referrerPolicy: 'no-referrer' }));

// Full URL in Chromium; Firefox and WebKit send only the origin cross-site
console.log(await refererSentTo(echo, { referrerPolicy: 'unsafe-url' }));

On the test page it logged https://shop.example/, (none) and the full URL in Chromium 153, and https://shop.example/, (none) and https://shop.example/ in Firefox 155 and WebKit 26.6.

Good questions.