Referrer-Policy Explained

The Referrer-Policy header tells the browser how much of the current URL to reveal when a user clicks a link, loads an image, or makes any request to another site. Set it to a restrictive value and you stop your URLs, which often carry tokens and private paths, from leaking to third parties. It is one of the simplest privacy wins available among the HTTP security headers explained in the wider guide.

The referrer is the address of the page that triggered a request. By default a browser may attach it to outbound links, embedded images, fonts, and scripts. That sounds harmless until you remember what ends up in URLs: a password reset link, an unsubscribe token, an internal report path, or a search query. Any of those can be handed to an ad network or external CDN without the user ever knowing. Referrer-Policy sits alongside the other headers covered in HTTP security headers explained and gives you direct control over that exposure.

Why a leaking referrer matters

Picture a user resetting their password. The reset URL contains a one-time code. If that page embeds a third-party analytics script and the referrer is sent in full, the analytics vendor now holds a working reset link. The W3C Referrer Policy specification describes the referrer as a deliberate privacy and security surface for exactly this reason, and the OWASP Secure Headers project lists Referrer-Policy among the headers every site should set explicitly rather than leaving to chance.

There is also a downgrade concern. Sending an HTTPS URL to an HTTP destination exposes that address over an unencrypted connection. Sensible policies strip the referrer entirely on that downgrade.

The common values

Each value answers one question: how much do I send, and to whom? Here is the practical breakdown.

Value	What it sends
no-referrer	Nothing, ever. No referrer header on any request.
no-referrer-when-downgrade	Full URL, except when going from HTTPS to HTTP, where it sends nothing.
same-origin	Full URL for same-origin requests; nothing cross-origin.
origin	Only the origin (scheme, host, port), never the path or query.
strict-origin	Origin only, and nothing on an HTTPS to HTTP downgrade.
origin-when-cross-origin	Full URL same-origin; origin only across origins.
strict-origin-when-cross-origin	Full URL same-origin; origin only cross-origin; nothing on downgrade.
unsafe-url	Full URL to every destination, including downgrades. Avoid this.

The names look repetitive, so read them as a formula. "strict" means drop the referrer on a secure-to-insecure downgrade. "origin" means send only the host, not the path. "cross-origin" qualifiers change behavior depending on whether the destination shares your origin.

The modern browser default

If you send no header at all, current browsers fall back to strict-origin-when-cross-origin. That default is itself a strong choice: same-origin requests keep the full URL, cross-origin requests leak only your origin, and any downgrade to HTTP sends nothing. The W3C specification documents this as the recommended baseline.

Relying on the default works, but setting the header explicitly is still worth doing. It makes your intent visible in audits, protects you against older clients that predate the default, and signals to reviewers that the choice was deliberate.

How to choose

Pick based on how much your URLs reveal and how much outbound analytics you depend on.

• Set no-referrer when pages carry tokens, reset codes, or private identifiers and you have no need to pass referrer data anywhere.
• Use strict-origin-when-cross-origin for most sites. It matches the browser default and balances privacy with the referrer data marketing and analytics teams expect.
• Reach for same-origin when you want internal navigation tracking but refuse to share anything with external destinations.
• Treat unsafe-url as a mistake. It hands your full URLs to everyone, downgrades included.

You can also override the page-level policy on individual links with the referrerpolicy attribute or a rel="noreferrer" value, which is handy for a single sensitive outbound link without changing the site-wide header.

Once it is live, confirm the header actually reaches the browser; misconfigured proxies and CDNs sometimes strip it. The companion guide on how to check security headers walks through verifying that the value you set is the value users receive.

A short checklist before you ship: decide whether any URL on the site contains a secret, choose the most restrictive value that still meets your analytics needs, set the header server-side, and test it.

Want to see which referrer policy a site is sending right now? Scan any domain's headers free at domainintel.app and review the full report in seconds.