Referrer Policy Explained
Understand the Referrer-Policy HTTP header, how browsers send referrer information and which policy is best for different websites.
Referrer Policy is a browser security and privacy feature that controls how much information about the current page is included in the Referer HTTP request header when users navigate to another page or when browsers request external resources. Proper configuration helps reduce unnecessary information disclosure while still allowing websites to collect useful analytics and support legitimate functionality.
Modern browsers support several Referrer Policy values, allowing website owners to choose the balance between privacy, compatibility and debugging needs.
What Is Referrer Policy?
Referrer Policy defines when browsers send the Referer header and how much of the original URL is shared with the destination. Depending on the selected policy, browsers may send the full URL, only the origin or no referrer information at all.
What Is the Referer Header?
The Referer HTTP request header tells the destination website which page initiated the request. It is commonly used for analytics, traffic attribution, diagnostics and access control. Despite the unusual spelling, 'Referer' is the official HTTP header name defined by the standard.
Referer: https://example.com/products/item-123Why Referrer Information Matters
URLs sometimes contain sensitive information such as search terms, internal paths or query parameters. Sending the complete URL to another website may unintentionally expose information that should remain private.
- Improve user privacy.
- Reduce information leakage.
- Control analytics data.
- Limit exposure of URL parameters.
- Support secure cross-origin navigation.
How Referrer Policy Works
When the browser prepares an outgoing request, it evaluates the active Referrer Policy and determines whether the Referer header should be omitted, contain only the origin or include the complete URL.
User Clicks Link
↓
Browser Evaluates Policy
↓
Referer Header Modified
↓
Request SentCommon Referrer Policy Values
| Policy | Behavior |
|---|---|
| no-referrer | Never send the Referer header |
| origin | Send only the scheme, host and port |
| same-origin | Send referrer only for same-origin requests |
| strict-origin | Send origin only over equally secure connections |
| strict-origin-when-cross-origin | Full URL for same-origin, origin for secure cross-origin requests |
The Default Browser Behavior
Most modern browsers use strict-origin-when-cross-origin as the default behavior. This provides a good balance between privacy and compatibility by sending full URLs only within the same origin while limiting information shared with other websites.
How Referrer Policy Is Configured
The policy is commonly delivered using the Referrer-Policy HTTP response header, although it can also be specified using HTML meta tags for individual documents.
Referrer-Policy: strict-origin-when-cross-originUnderstanding Policy Values
Each Referrer Policy value determines how much information browsers include in the Referer header under different navigation scenarios. Choosing the appropriate value depends on the balance between privacy, compatibility and analytics requirements.
| Policy | Typical Use Case |
|---|---|
| no-referrer | Maximum privacy |
| origin | Share only the website origin |
| same-origin | Internal applications |
| strict-origin | Privacy-focused websites |
| strict-origin-when-cross-origin | General-purpose websites |
| unsafe-url | Rarely recommended |
Same-Origin vs Cross-Origin Requests
A same-origin request targets the same protocol, host and port as the current page. A cross-origin request targets a different origin. Referrer Policy often applies different rules depending on whether the destination is same-origin or cross-origin.
| Request Type | Example |
|---|---|
| Same-Origin | example.com → example.com |
| Cross-Origin | example.com → another-site.com |
When the Referer Header Is Used
Browsers may include the Referer header during page navigation and when requesting many external resources. The active Referrer Policy determines whether the header is omitted, shortened or sent in full.
- Opening hyperlinks.
- Loading images.
- Downloading stylesheets.
- Fetching JavaScript files.
- Making network requests from web pages.
Privacy Benefits
Restricting referrer information reduces accidental disclosure of internal URLs, search terms and query parameters. This is particularly valuable when users navigate from authenticated areas or pages containing sensitive identifiers.
Analytics Considerations
Some analytics platforms rely on the Referer header to identify traffic sources. More restrictive policies may reduce the amount of available referral information, so organizations should evaluate privacy and reporting requirements together.
Interaction with HTTPS
Modern Referrer Policy values help prevent secure HTTPS pages from exposing unnecessary information when users navigate to less secure destinations. This reduces information leakage during protocol transitions.
Choosing the Right Policy
| Priority | Recommended Policy |
|---|---|
| Maximum privacy | no-referrer |
| Balanced security | strict-origin-when-cross-origin |
| Internal applications | same-origin |
| Origin-only sharing | origin |
Deployment Recommendations
Most public websites can safely use strict-origin-when-cross-origin because it preserves useful same-origin behavior while limiting information shared with external websites. More restrictive policies may be appropriate for privacy-sensitive applications.
Common Mistakes
Referrer Policy is often configured only after a privacy issue is discovered. In many cases, websites either expose more information than necessary or choose an overly restrictive policy without considering its effect on analytics and integrations.
- Using unsafe-url without a specific business requirement.
- Including sensitive data in URL paths or query parameters.
- Assuming Referrer Policy replaces proper access control.
- Choosing no-referrer without evaluating analytics requirements.
- Ignoring browser defaults when deploying custom policies.
- Forgetting to test third-party integrations after changing the policy.
Best Practices
- Use strict-origin-when-cross-origin for most public websites.
- Avoid placing sensitive information in URLs.
- Review analytics and third-party services before changing the policy.
- Apply a consistent Referrer Policy across the entire application.
- Test cross-origin integrations after deployment.
- Combine Referrer Policy with other HTTP security headers.
Frequently Asked Questions
What is the recommended Referrer Policy?
For most modern websites, strict-origin-when-cross-origin is recommended because it balances privacy, compatibility and analytics. It sends the full URL for same-origin requests while limiting cross-origin requests to the origin only.
Does Referrer Policy improve security?
Yes. It helps reduce accidental disclosure of internal URLs, query parameters and navigation paths, improving both privacy and security by limiting unnecessary information sharing.
Can Referrer Policy stop tracking completely?
No. It controls only the Referer HTTP header. Websites can still use cookies, JavaScript, browser fingerprinting and other techniques to collect information unless additional privacy protections are implemented.
Should I use no-referrer?
It depends on your requirements. no-referrer provides the strongest privacy by never sending the Referer header, but it may reduce analytics data and affect services that rely on referral information.
Does Referrer Policy affect same-origin requests?
Some policies do. For example, same-origin sends referrer information only within the same origin, while strict-origin-when-cross-origin sends the full URL for same-origin requests and only the origin for secure cross-origin requests.
Helpful HTTP Header Tools
A Referrer Policy Generator creates correctly formatted Referrer-Policy headers, an HTTP Header Generator builds custom HTTP response headers for testing, a Security Headers Generator configures multiple recommended security headers together, an HTTP Header Viewer displays the response headers returned by a website for verification, and a Permissions Policy Generator helps configure browser feature restrictions that complement other security header protections.
Conclusion
Referrer Policy gives website owners fine-grained control over how much navigation information browsers share with other websites. By selecting an appropriate policy, organizations can reduce unnecessary information disclosure, improve user privacy and maintain compatibility with modern web applications. When combined with HTTPS and other HTTP security headers, Referrer Policy forms an important part of a comprehensive web security strategy.