Referrer-Policy

Every time your page triggers a request (a link click, an image load, a fetch), the browser attaches a Referer header to tell the destination where the request came from. Historically this was the full URL of your page. URLs often contain things the destination has no business seeing: password-reset tokens, session IDs, email addresses in query strings, ticket identifiers.

Referrer-Policy is the response header that tells the browser what is allowed in that Referer. The right policy gives analytics what they need (origin) without leaking your URL path.

What leaks

Toggle between policies to see what a third-party load actually gets told.

What leaks in Referer
user is on your page
https://example.com/reset?token=abc123secret
page loads<img src="https://analytics.vendor.com/pixel.png">
browser sends to vendor.com
Referer: https://example.com/reset?token=abc123secret
full URL leaked. The reset token is now in vendor.com's access logs. This was the default before November 2020.

The URL at the top is a password-reset link. Every image, script, iframe, or fetch your page triggers can send that URL to the destination as a Referer. Every third-party embed is a potential log line of the exact URL the user was on.

What changed in 2020

Historically the default was no-referrer-when-downgrade: full URL to any HTTPS destination, which meant every analytics pixel got your path and query. In November 2020 the Fetch spec changed the default to strict-origin-when-cross-origin. Chrome, Firefox, Safari, and Edge all shipped the new default by mid-2021.

Modern browsers now default to sane. The argument for setting the header explicitly is consistency: old clients, embedded browsers, and anything exotic still might use the old default. Pinning the policy avoids surprises.

The values

The eight valuesW3C Referrer Policy
no-referrer
nothing, ever
strongest privacy; breaks attribution
pass
same-origin
full URL for same-origin, nothing for cross-origin
good for internal apps
pass
strict-origin
origin only on HTTPS to HTTPS; nothing on downgrade
simple and private
pass
strict-origin-when-cross-origin
full URL for same-origin, origin for cross-origin (HTTPS only)
current default since Nov 2020; recommended explicit setting
pass
origin
origin only, always
simpler than strict-origin but leaks on downgrade
warn
origin-when-cross-origin
full for same-origin, origin for cross-origin
ignores HTTPS downgrade
warn
no-referrer-when-downgrade
full URL unless HTTPS to HTTP
former default, leaks URLs to HTTPS third parties
fail
unsafe-url
full URL, always
do not ship this
fail

Specified in the W3C Referrer Policy.

What to ship

For almost every public site:

Referrer-Policy: strict-origin-when-cross-origin

Same-origin navigations keep the full URL (useful for your own analytics). Cross-origin requests send only the origin. HTTPS-to-HTTP downgrades send nothing. This matches the modern browser default while making the intent explicit.

For a privacy-focused site that does not need cross-origin attribution, step up to strict-origin or no-referrer.

Per-element overrides

The header sets the default for the whole page. You can loosen or tighten it on specific elements:

<a href="https://partner.example.com" referrerpolicy="no-referrer">...</a>
<img src="https://cdn.example.com/pixel.png" referrerpolicy="origin">

Or even per-request in fetch:

fetch(url, { referrerPolicy: 'no-referrer' })

Useful when one specific integration needs a different policy than the page default.

Common mistakes

unsafe-url

Sends the full URL to every destination, including over HTTP. Leaks on downgrade. Never ship.

no-referrer-when-downgrade (old default)

Leaks full URLs to every HTTPS third party (almost all of them). An attacker running an ad-tech pixel or CDN sees your password-reset links. Use strict-origin-when-cross-origin instead.

relying on the browser default

The default is good today but has changed before. Old browsers, webviews, and embedded browsers may still have the old behaviour. Set the header explicitly.

secrets in URL query strings

Referrer-Policy limits the damage but does not eliminate it. Self-referencing requests, same-origin scripts, and browser history still see the URL. Keep secrets out of query strings when you can.

no-referrer breaking OAuth

Some OAuth flows require a same-origin or same-site referrer to detect the origin of the request. Global no-referrer can break them. Override per-request with referrerpolicy if needed.


Check what Referrer-Policy your site sends, and what leaks in the Referer header when third parties load your pages: scan your domain.