Every time a user clicks a link and navigates to another page, the browser can send a Referer header to the destination server revealing where the user came from. The Referrer-Policy header gives website owners control over exactly how much of this information is shared — balancing user privacy, security, and the needs of analytics.
What Is the Referrer Header?
The HTTP Referer header (note: the original HTTP specification misspells "referrer") is sent by browsers when making requests. It tells the destination server the URL of the page the user was on when they clicked a link or triggered a request.
For example, if a user on https://example.com/pricing clicks a link to https://partner.com/checkout, the browser sends:
Referer: https://example.com/pricingThis can leak sensitive information: query strings with user IDs, session tokens in URLs, internal page paths, or information about authenticated sections of your site.
What Is the Referrer-Policy Header?
The Referrer-Policy HTTP response header (correctly spelled with double 'r') tells the browser how to handle the Referer header for requests originating from your page. It can be sent as an HTTP response header or specified in an HTML <meta> tag.
Referrer-Policy: strict-origin-when-cross-origin<meta name="referrer" content="strict-origin-when-cross-origin">Referrer-Policy Values
| Policy Value | Same-Origin Requests | Cross-Origin (HTTPS→HTTPS) | Downgrade (HTTPS→HTTP) |
|---|---|---|---|
no-referrer | No header sent | No header sent | No header sent |
no-referrer-when-downgrade | Full URL | Full URL | No header sent |
origin | Origin only | Origin only | Origin only |
origin-when-cross-origin | Full URL | Origin only | Origin only |
same-origin | Full URL | No header sent | No header sent |
strict-origin | Origin only | Origin only | No header sent |
strict-origin-when-cross-origin | Full URL | Origin only | No header sent |
unsafe-url | Full URL | Full URL | Full URL |
Policy Values Explained
no-referrer
No Referer header is ever sent, for any request. Provides maximum privacy but means that third-party analytics, affiliate tracking, and other referrer-dependent systems receive no information about where visitors came from.
no-referrer-when-downgrade
This was the old browser default before the Referrer-Policy header existed. Sends the full URL as the referrer for HTTPS-to-HTTPS and HTTP-to-HTTP requests, but suppresses the header when navigating from HTTPS to HTTP (to avoid leaking sensitive URLs over unencrypted connections). Not recommended as the explicit default for new sites.
origin
Sends only the origin (scheme + host + port: https://example.com) — never the full path. This lets the destination know which site referred the user without revealing the specific page or any query parameters.
strict-origin-when-cross-origin (Recommended)
This is the current browser default and the recommended choice for most websites. It:
- Sends the full URL for same-origin requests (useful for internal analytics).
- Sends only the origin for cross-origin HTTPS-to-HTTPS requests.
- Sends nothing when navigating from HTTPS to HTTP (preventing leaks over unencrypted connections).
Referrer-Policy: strict-origin-when-cross-originunsafe-url
Always sends the full URL as the referrer, even on downgrade from HTTPS to HTTP. This is dangerous — it can leak sensitive URL parameters (including tokens, session IDs, and personal information) over unencrypted connections. Avoid this value.
unsafe-url on production websites. It defeats the privacy protections of HTTPS and can leak sensitive URL parameters to third parties and over unencrypted connections.Impact on Analytics
Referrer-Policy affects how analytics tools (Google Analytics, Plausible, etc.) attribute traffic sources. If your policy is too restrictive:
- Traffic may be misattributed to "Direct" instead of the actual referral source.
- Campaign tracking parameters in URLs may not be preserved in referrer data.
- Affiliate and partner tracking may be broken.
strict-origin-when-cross-origin is a good balance — external sites see only your origin (which is enough for analytics attribution) while your full page paths are not leaked.
Setting Referrer-Policy in Web Servers
# Nginx
add_header Referrer-Policy "strict-origin-when-cross-origin" always;# Apache
Header always set Referrer-Policy "strict-origin-when-cross-origin"// Next.js next.config.mjs
const nextConfig = {
async headers() {
return [
{
source: '/(.*)',
headers: [
{ key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
],
},
];
},
};Checking Your Referrer-Policy Header
Use the ShowDNS Security Headers checker to verify the Referrer-Policy header on your website, along with all other HTTP security headers.
Frequently Asked Questions
What is the default Referrer-Policy if none is set?
Modern browsers default to strict-origin-when-cross-origin when no Referrer-Policy header is set. However, explicitly setting the header in your server configuration ensures consistent behavior across all browsers.
Does Referrer-Policy affect SEO?
The Referrer-Policy does not directly affect SEO rankings. However, it can affect how traffic sources are attributed in analytics tools. Stricter policies may result in more traffic being classified as "direct" rather than "referral", which affects your analytics data but not your search rankings.
Can I set different Referrer-Policy values for different links?
Yes. You can set the referrerpolicy attribute on individual <a>, <img>, <link>, and <iframe> elements to override the page-level policy for specific resources.
Is Referrer-Policy the same as Content Security Policy?
No. Referrer-Policy controls what URL information is sent in the Referer header. Content Security Policy controls what resources (scripts, styles, images) a page is allowed to load. Both are security headers but serve different purposes.