Referrer-Policy Header Explained

Jul 16, 2026
Updated Jul 16, 2026 Security Headers referrer-policy referrer policy header strict-origin-when-cross-origin referrer policy values

The Referrer-Policy HTTP response header controls how much of the current URL a browser includes in the Referer header when a user follows a link or a page loads a resource. Tuning it protects privacy and prevents sensitive information in URLs — session tokens, reset links, internal paths — from leaking to third-party sites.

What is the Referrer-Policy header?

By default, browsers send the address of the previous page in the Referer request header. That is useful for analytics but risky: if your URLs contain secrets or reveal internal structure, every outbound link and third-party asset can leak them. Referrer-Policy lets you decide exactly how much of that information is shared, from everything down to nothing.

Common Referrer-Policy values

ValueWhat is sent
no-referrerNothing — the Referer header is omitted entirely.
same-originThe full URL for same-origin requests, nothing for cross-origin.
strict-originOnly the origin (scheme + host), and only over equally secure connections.
strict-origin-when-cross-originFull URL to the same origin; only the origin to other sites. The modern browser default.
no-referrer-when-downgradeFull URL except when moving from HTTPS to HTTP. The older default.

Example Referrer-Policy header

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

This sends the full path within your own site (useful for analytics) but only your bare origin to external sites, so no sensitive path ever leaves your domain. For higher-privacy sites, no-referrer or same-origin is stricter.

How to check Referrer-Policy

See a site's Referrer-Policy with the free HTTP headers checker, or review it with the rest of a site's headers in the security headers guide.

Why it matters

  • Stops secret-in-URL leaks. Password-reset tokens or session IDs placed in URLs will not be handed to third-party analytics, ad, or CDN requests.
  • Reduces internal-structure disclosure. External sites learn only your origin, not your internal paths.
  • Improves privacy. Less of your users' browsing context is shared with the sites they visit next.

Common mistakes

  • Leaving the default when URLs hold secrets. If any URL can contain a token, set at least strict-origin-when-cross-origin — and better, keep secrets out of URLs entirely.
  • Using unsafe-url. This sends the full URL everywhere, including cross-origin and downgrades — the opposite of what you usually want.

Related security headers

Referrer-Policy is part of the baseline set alongside X-Content-Type-Options and X-Frame-Options, complementing Content-Security-Policy and Permissions-Policy.

Frequently asked questions

What is the best Referrer-Policy?

strict-origin-when-cross-origin is a strong default that preserves same-site analytics while never leaking paths to other sites. For maximum privacy use no-referrer.

Does Referrer-Policy affect my analytics?

Same-origin analytics keep the full path under strict-origin-when-cross-origin. Third-party analytics on other domains will see only your origin, not full URLs.

Why is "Referer" spelled differently?

The request header Referer was misspelled in the original HTTP specification and kept for compatibility. The newer policy header uses the correct spelling, Referrer-Policy.

Scan for these vulnerabilities

Secably automatically detects the issues discussed in this article.

Start Free Scan