Referrer-Policy Recommender

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.

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.

Full comparison of all eight policy values

The table below shows what each value puts in the Referer header across three situations: same origin, cross origin, and an HTTPS to HTTP downgrade. "Full URL" includes the path and query string; "Origin only" means just scheme + host + port (e.g. https://example.com); "None" means no header is sent at all.

A worked example

Suppose a user on https://shop.example.com/order?token=abc123&email=kim@test.com navigates to an external payment provider at https://pg.partner.com. Both are HTTPS, so this is not a downgrade, and the host differs, so it counts as "cross origin":

• unsafe-url → Referer: https://shop.example.com/order?token=abc123&email=kim@test.com (token and email leak verbatim)
• no-referrer-when-downgrade → the same full URL leaks (HTTPS→HTTPS, so the downgrade protection never kicks in)
• strict-origin-when-cross-origin → Referer: https://shop.example.com (origin only, token protected)
• no-referrer → no Referer header at all

Common pitfall

The most common misconception is that no-referrer-when-downgradeis a "safe" choice. The "downgrade" in its name only protects the HTTPS→HTTP case; for today's typical HTTPS-to-HTTPS cross-origin navigation it still sends the full URL, query string included. On the modern web that is effectively the same exposure as unsafe-url — so if your goal is "send only the origin", you must pick strict-origin-when-cross-origin or strict-origin instead.