Use strict-origin-when-cross-origin for Referrer-Policy

For almost every site, the right answer is strict-origin-when-cross-origin — which is also the default modern browsers apply when no policy is set. It sends the full URL as the Referer header on same-origin requests, sends only the origin (scheme, host, port — no path or query) on cross-origin requests, and sends nothing at all when navigating from HTTPS to HTTP. That combination keeps analytics useful within your own site while preventing paths, query strings, and tokens from leaking to third parties or downgraded connections. You set it once as a header:

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

The spectrum of policies

Referrer-Policy values trade privacy against how much referrer data downstream tools receive. From most private to least:

• no-referrer — never send Referer. Maximum privacy; breaks analytics and any backend that reads the referrer.
• same-origin — full URL to your own origin, nothing cross-origin.
• strict-origin — only the origin, and only when not downgrading to HTTP. Never sends a path, even same-origin.
• strict-origin-when-cross-origin — the recommended default: full URL same-origin, origin-only cross-origin, nothing on downgrade.
• origin-when-cross-origin — like the above but still leaks the origin even on an HTTPS-to-HTTP downgrade.
• no-referrer-when-downgrade — the legacy default: full URL everywhere except on downgrade. Leaks full paths and queries to every cross-origin destination.
• unsafe-url — full URL always, including on downgrade. Leaks the most; avoid it.

There is also origin (always send origin only) and the empty value (fall back to the browser default).

The privacy-versus-analytics tradeoff

The reason strict-origin-when-cross-origin is the sweet spot: the full URL — including paths and query parameters that may carry session ids, search terms, or reset tokens — stays inside your own origin, where you already control it. Cross-origin destinations learn only that a visit came from your domain, not which page. That is usually enough for referral attribution while denying third parties (ad networks, embedded widgets, outbound links) the rest of the URL.

If you genuinely need full cross-origin referrers for an analytics integration, prefer scoping the relaxation to specific links rather than weakening the whole site, and never use unsafe-url, which sends full URLs over insecure connections too.

Setting it: header, meta, or per-link

You can apply the policy at three scopes:

• HTTP header (site-wide, recommended): Referrer-Policy: strict-origin-when-cross-origin.
• HTML <meta> for static pages without header control: a meta element with name="referrer" and content="strict-origin-when-cross-origin".
• Per-link override with the referrerpolicy attribute on a, img, link, or iframe, or rel="noreferrer" to strip the referrer for a single link.

The header wins as the baseline; element-level attributes refine individual requests. Setting the header explicitly is still worth doing even though browsers default to this value, because it documents intent and protects users on older clients.

Check your security headers →

Further reading

• Security headers: a practical guide to the ones that matter
• Permissions-Policy: disable the browser features your site never uses
• Should I enable HSTS? What it does and how to roll it out
• W3C Referrer Policy specification