OneWebDesk

Referrer-Policy Recommender

Recommend a Referrer-Policy value for your site type and compare how each value behaves.

The Referrer-Policy response header controls how much of the originating URL the browser places in the Referer header when a user follows a link or loads a resource. Send too much and the full URL — including query strings and session tokens — can leak to third parties; send too little and referral analytics or some authentication flows may break.

Pick your site profile (general, privacy-sensitive, or analytics/ad-dependent) and this tool instantly recommends a Referrer-Policy value, then compares the behavior of all eight policy values side by side. For a full audit of your response headers see Security Headers Checker, and for the Content-Security-Policy you usually set alongside it, try the CSP Generator.

Recommended Referrer-Policy
strict-origin-when-cross-origin
Response headerReferrer-Policy: strict-origin-when-cross-origin
WhyThis matches the modern browser default. Full URL to same origin, only the origin cross-origin, and nothing on a downgrade — the best balance of safety and compatibility.
All 8 policy values compared
ValueBehavior
no-referrerNever sends a Referer under any circumstances
no-referrer-when-downgradeSends the full URL unless it is a downgrade (HTTPS to HTTP) (legacy default)
originAlways sends only the origin (scheme + host + port)
origin-when-cross-originFull URL to same origin, only the origin cross-origin
same-originFull URL to same origin, nothing cross-origin
strict-originSends only the origin, and nothing on a downgrade
strict-origin-when-cross-originFull URL same-origin, origin cross-origin, nothing on a downgrade (current default)
unsafe-urlNot recommendedAlways sends the full URL, including on a downgrade — risky, not recommended

Why strict-origin-when-cross-origin is the default

Modern browsers use strict-origin-when-cross-origin when no policy is set. It sends the full URL to the same origin, only the origin to cross-origin destinations, and nothing on an HTTPS to HTTP downgrade. That strikes a balance: analytics tools can still recognize the referring domain, while paths and query strings stay private.

  • General site: strict-origin-when-cross-origin (effectively the default)
  • Privacy-sensitive: no-referrer or same-origin
  • Analytics / ad-dependent: strict-origin-when-cross-origin (keeps the origin)

Values to avoid

unsafe-url always sends the full URL, even on a downgrade. Tokens, emails, or search terms in the query string can be handed to third parties verbatim, so it is discouraged in almost every case. no-referrer-when-downgrade is the old permissive default and leaks the full URL cross-origin, so avoid choosing it explicitly.

How to apply it

Setting it as a server response header is the most reliable approach. In nginx use add_header Referrer-Policy "strict-origin-when-cross-origin" always;; as a meta tag use <meta name="referrer" content="strict-origin-when-cross-origin">. When both are present, the header generally takes precedence.

Frequently asked questions

Isn't the Referer header misspelled?
Yes. The HTTP header name was locked in as 'Referer' due to a typo in the original spec, while the policy header and the JavaScript API use the correct 'Referrer' spelling. So the header is Referer but the policy is Referrer-Policy.
For a privacy-sensitive site, should I use no-referrer or same-origin?
If you never want even the origin sent externally, no-referrer is safest. But if you still need referral analytics between pages on your own domain, same-origin is better: it sends the full URL to the same origin and nothing to external sites.
What happens to analytics/ads if I block the referrer?
With no-referrer, traffic gets lumped into 'direct', making campaign attribution hard. strict-origin-when-cross-origin hides the path and query but keeps the origin domain, so analytics tools can still recognize the referring site.
Which wins, the meta tag or the response header?
When both are set, the HTTP response header generally takes precedence. The header also applies from the very first request, whereas a meta tag only takes effect after the HTML is parsed, so prefer the server header when possible.
Are my inputs sent to a server?
No. All recommendation logic runs entirely in your browser, and neither the site profile you choose nor the generated header string is ever transmitted or stored anywhere.

Related tools

Web Security