Referrer-Policy Header Explained
The Referrer-Policy HTTP response header controls how much of the current URL a browser includes in the Referer header when a user follows a link or a page loads a resource. Tuning it protects privacy and prevents sensitive information in URLs — session tokens, reset links, internal paths — from leaking to third-party sites.
What is the Referrer-Policy header?
By default, browsers send the address of the previous page in the Referer request header. That is useful for analytics but risky: if your URLs contain secrets or reveal internal structure, every outbound link and third-party asset can leak them. Referrer-Policy lets you decide exactly how much of that information is shared, from everything down to nothing.
Common Referrer-Policy values
| Value | What is sent |
|---|---|
no-referrer | Nothing — the Referer header is omitted entirely. |
same-origin | The full URL for same-origin requests, nothing for cross-origin. |
strict-origin | Only the origin (scheme + host), and only over equally secure connections. |
strict-origin-when-cross-origin | Full URL to the same origin; only the origin to other sites. The modern browser default. |
no-referrer-when-downgrade | Full URL except when moving from HTTPS to HTTP. The older default. |
Example Referrer-Policy header
Referrer-Policy: strict-origin-when-cross-origin
This sends the full path within your own site (useful for analytics) but only your bare origin to external sites, so no sensitive path ever leaves your domain. For higher-privacy sites, no-referrer or same-origin is stricter.
How to check Referrer-Policy
See a site's Referrer-Policy with the free HTTP headers checker, or review it with the rest of a site's headers in the security headers guide.
Why it matters
- Stops secret-in-URL leaks. Password-reset tokens or session IDs placed in URLs will not be handed to third-party analytics, ad, or CDN requests.
- Reduces internal-structure disclosure. External sites learn only your origin, not your internal paths.
- Improves privacy. Less of your users' browsing context is shared with the sites they visit next.
Common mistakes
- Leaving the default when URLs hold secrets. If any URL can contain a token, set at least
strict-origin-when-cross-origin— and better, keep secrets out of URLs entirely. - Using
unsafe-url. This sends the full URL everywhere, including cross-origin and downgrades — the opposite of what you usually want.
Related security headers
Referrer-Policy is part of the baseline set alongside X-Content-Type-Options and X-Frame-Options, complementing Content-Security-Policy and Permissions-Policy.
Frequently asked questions
What is the best Referrer-Policy?
strict-origin-when-cross-origin is a strong default that preserves same-site analytics while never leaking paths to other sites. For maximum privacy use no-referrer.
Does Referrer-Policy affect my analytics?
Same-origin analytics keep the full path under strict-origin-when-cross-origin. Third-party analytics on other domains will see only your origin, not full URLs.
Why is "Referer" spelled differently?
The request header Referer was misspelled in the original HTTP specification and kept for compatibility. The newer policy header uses the correct spelling, Referrer-Policy.