Referrer-Policy: the Privacy Header 91% of the Web Forgot
Published
Figures as of 2026-08-16 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.
The headline: 91.4% of the web never states a referrer policy
Of 231,968,605 HTTP responses we examined in the August 2026 census, 211,984,975 — 91.4% — carried no Referrer-Policy header at all. One line of configuration decides whether your site tells other sites which page your visitors were just reading. Nine sites in ten leave that line blank.
Referrer-Policy is the least glamorous header in the security canon. It stops no malware. It blocks no injection. What it controls is quieter: every time a visitor clicks a link on your site, or your page loads an image, script or analytics beacon from someone else’s server, the browser can attach the full URL of the page they were on. Search terms in the query string. Account-area paths. The occasional password-reset token some framework put in a URL because it was Tuesday. The Referrer-Policy header is where a site says how much of that gets shared. Almost nobody says anything.
Key findings
- 91.4% of HTTP responses send no Referrer-Policy header — 211,984,975 of the 231,968,605 responses in this cut of the August 2026 census.
- Only 19,983,630 responses (8.6%) set the header at all, and that count is a floor (top-values basis; see method).
- Among sites that do set it, two values own the market: strict-origin-when-cross-origin (44.0%) and same-origin (39.4%) — 83.4% combined.
- 1,532,662 responses — 7.7% of deployers — explicitly chose a leaky value: no-referrer-when-downgrade (1,463,411) or unsafe-url (69,251), both of which send the full URL to other sites.
- 367,245 responses sent the Referrer-Policy header more than once, and 74,321 sent it empty — configured, but configured wrong.
- Our stricter methodology check passes just 6.8% of the 120.8 million domains it applies to (8,245,565 of 120,844,394).
What does Referrer-Policy actually control?
When a browser navigates from page A to page B, or fetches a resource for page A from another server, it can include a Referer header naming the page the request came from. (Yes, one “r” — the misspelling shipped in an early HTTP spec and stuck; that detail is industry history, not census data.)
The privacy problem is that URLs carry meaning. A referrer of https://example-clinic.example/conditions/some-diagnosis tells the ad network that served a font exactly what the visitor was reading. A referrer with ?q=redundancy+letter+template shares a search. Session identifiers and one-time tokens end up in URLs more often than anyone intends, and the referrer dutifully exports them.
Referrer-Policy is the site’s dial for this. no-referrer sends nothing. same-origin shares full URLs only with your own site. strict-origin-when-cross-origin — the modern sensible default — sends the full URL within your site but only the bare origin (https://example.com/, no path) to anyone else. At the other end sits unsafe-url, which shares the complete URL with everyone, always, and wears its own warning label in its name.
One header value. That’s the entire cost of choosing. The census says 91.4% of the web hasn’t chosen.
Who decides, if the site doesn’t?
The browser does. And this is where the story gets more interesting than another adoption-is-low chart.
For most of the web’s history, the effective default was no-referrer-when-downgrade: send the full URL to everyone, on every cross-site request, trimming it only when moving from HTTPS to plain HTTP. Full-path leakage was the factory setting of the web. Then the browsers moved — Chrome switched its default to strict-origin-when-cross-origin in version 85 (2020) and Firefox followed in version 87 (2021). Those dates and defaults are industry knowledge, not something our scanner measures.
The consequence is odd and worth sitting with. The 91% of sites that never set the header are mostly fine today — not because they did anything, but because the browser vendors quietly changed the factory setting underneath them. The web’s referrer privacy improved by roughly two orders of magnitude more through two browser releases than through a decade of site operators editing config files.
That rescue has edges, though. It protects visitors using current mainstream browsers. Older browsers, embedded webviews and assorted non-browser HTTP clients follow their own rules, and a site with no policy has expressed no preference for them to honour. The header is also the only place a site can pick something stricter than the browser default: same-origin and no-referrer don’t happen unless you ask. The silent 91% are renting their privacy posture from the browser vendors, on terms the vendors can change again.
Which Referrer-Policy values dominate among the 8.6% who set one?
Here is the full value distribution among the 19,983,630 responses that set the header (the 24 most common observed values; single-value rows unless marked):
| Value | Responses | Share of deployers |
|---|---|---|
| strict-origin-when-cross-origin | 8,792,850 | 44.0% |
| same-origin | 7,874,295 | 39.4% |
| no-referrer-when-downgrade | 1,463,411 | 7.3% |
| no-referrer | 939,687 | 4.7% |
| header sent twice (all combinations) | 367,245 | 1.8% |
| strict-origin | 173,237 | 0.9% |
| origin-when-cross-origin | 152,584 | 0.8% |
| origin | 76,749 | 0.4% |
| (empty value) | 74,321 | 0.4% |
| unsafe-url | 69,251 | 0.3% |
Two readings jump out.
First, the deployers mostly deploy well. strict-origin-when-cross-origin plus same-origin is 83.4% of everyone who set the header. Add no-referrer and strict-origin and roughly nine in ten explicit policies are privacy-protective. The population that thinks about this header at all mostly reaches a sound answer — which is precisely the pattern you’d expect when the hard part is remembering the header exists, not understanding it.
Second, the exceptions are instructive. The 1,463,411 responses pinning no-referrer-when-downgrade have explicitly locked in the old leaky default — full URLs to every third party — including against the browser improvements that would otherwise have rescued them. Some of that is surely cargo-culted config copied years ago. The 69,251 declaring unsafe-url (plus 3,011 more declaring it twice, for 72,262 total) went further and switched every safety off by hand; a fraction of those are deliberate analytics choices, the rest are the same value copied without the reading. Together, the explicitly leaky cohort is 1,532,662 responses — 7.7% of everyone who bothered to configure the header configured it to share more than a modern browser would share on its own.
And then there’s the pure noise: 74,321 sites sending the header with an empty value, and 367,245 sending it twice — usually the application and a CDN or reverse proxy each adding their own copy. Browsers resolve duplicate and invalid values by rule, so most of these still land somewhere safe, but they’re a tidy little fossil record of layered infrastructure nobody audits. We found the same layering signature in what your server headers leak.
Does anyone do better? The TLD spread
Our methodology’s referrer-policy check — which requires an effective, protective policy, not mere header presence — passes 8,245,565 of the 120,844,394 domains where it applies: 6.8%. The spread across large TLDs (≥1M applicable domains) is wide:
| TLD | Check pass rate | Applicable domains |
|---|---|---|
| .shop | 18.6% | 1,609,901 |
| .fr | 10.0% | 1,228,916 |
| .nl | 9.1% | 1,253,812 |
| .uk | 8.8% | 2,362,568 |
| .de | 7.7% | 3,008,416 |
| .org | 5.9% | 4,161,544 |
| .net | 5.2% | 3,816,741 |
| .ru | 4.7% | 1,936,852 |
| .xyz | 3.7% | 3,433,382 |
.shop at 18.6% is the outlier, and the likeliest mechanism is boring: hosted commerce platforms ship the header as a platform default, so every store inherits it. European ccTLDs (.fr, .nl, .uk, .de) cluster above the global rate; the discount gTLDs (.xyz, .top) sit at the bottom. Where defaults are set by a platform, adoption quintuples. Where every operator must act individually, it collapses. That’s the same shape we found across every header in the HTTP security header report card, and it’s the shape of the whole internet security grade curve: security tracks whoever controls the defaults, not the diligence of individual owners.
Why should a non-security team care?
Because this header is a privacy control, and privacy is regulated in ways security hygiene isn’t. URLs routinely contain personal data — searches, account paths, tokens — and the referrer exports them to every third-party server your pages touch: ad networks, font CDNs, analytics endpoints, embedded widgets. A site that has never stated a referrer policy has never documented a decision about that flow. For a European operator writing GDPR records of processing, “we rely on whatever the visitor’s browser defaults to” is an uncomfortable sentence. (The regulatory framing is context, not legal advice, and not something the census measures.)
It is also the cheapest fix in this entire report series. One header. Any web server, CDN or framework can set it. strict-origin-when-cross-origin is safe for essentially every site and matches what modern browsers do anyway; same-origin is stricter and costs you only the referrer data you were giving other people. There is no migration, no certificate, no DNS propagation wait. The barrier is awareness, not cost — which is this report’s recurring finding, and nowhere more literally than here.
How we measured this
- Population and vantage: August 2026 census round (figures as of 2026-08-16, methodology v9), scanning from our EU measurement infrastructure. 376.9 million domains graded out of 432 million scanned. Headers are read from the response of the registered domain’s homepage fetch — one page, one vantage, at capture time. Subpages, subdomains and apps behind logins are not observed and may set different headers.
- Header-presence figures: the value-distribution cut covers 231,968,605 HTTP responses where the Referrer-Policy field was recorded; 211,984,975 had no header, 19,983,630 had one. The value table lists the 24 most common observed values, so the header-present count and per-value shares are floors; values outside that top list are not included. This denominator is smaller than the census’s full 376.9M graded-row HTTP basis; percentages here use the 231.97M cut and nothing else.
- Check-pass figures: the 6.8% figure (8,245,565 of 120,844,394) is our methodology’s referrer-policy check, which requires an effective protective policy and applies only where a domain serves gradeable web content. Check pass is not the same as header presence — the two denominators differ and are labelled separately throughout.
- Effective-policy caveat: when a response sends multiple or invalid values, browsers apply their own resolution rules; our value table reports what was sent, not what each browser ultimately enforced.
- Industry context is labelled: browser default changes (Chrome 85, Firefox 87), the Referer misspelling’s history, and regulatory framing are public industry knowledge, not census measurements.
- Aggregate only. We publish distributions and TLD-level figures. We never name or grade an individual registrant’s domain.
- Data is stored and processed within the EU.
What this means for IT teams, privacy leads, and business owners
For any organisation with a website that loads third-party resources — analytics, fonts, advertising, social widgets, payment scripts — the Referrer-Policy header is a documented privacy decision waiting to be made. Without an explicit policy, your site is leaking the full URL of every page a visitor was on when they triggered a third-party request, including any search terms, account path identifiers, or query-string tokens in those URLs. The browser’s modern default (strict-origin-when-cross-origin since Chrome 85 and Firefox 87) provides a degree of protection for current browser users, but it is not a documented organisational decision — it is a borrowed default that browser vendors can change.
For GDPR-regulated organisations, the question “what personal data do your pages send to third-party servers?” has Referrer-Policy as part of its answer. A site that sends full referrer URLs to an analytics CDN, an advertising network, or a font service is sending those URLs to a third-party data processor. Whether that constitutes a personal data transfer depends on the URL content. The cheapest way to remove the ambiguity is to set a policy that limits what is sent — strict-origin-when-cross-origin removes the path from cross-site requests entirely, which eliminates the class of accidental personal data sharing that arises from path-embedded identifiers.
The 1,532,662 organisations that explicitly configured a leaky value — no-referrer-when-downgrade or unsafe-url — deserve specific attention. These are not organisations that forgot the header; they are organisations that actively configured it to share more than the browser would have shared by default. Some of those are deliberate analytics configurations; others are cargo-culted config from a time before browser defaults improved. If your organisation’s web server sends no-referrer-when-downgrade or unsafe-url, check whether that policy is intentional and documented. If it is not, changing one line removes the data leakage.
Data to cite
- “91.4% of 231,968,605 HTTP responses measured in the August 2026 census carry no Referrer-Policy header — leaving browser defaults to decide whether full URLs are shared with every third-party server a page contacts.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “Only 8.6% of measured HTTP responses set a Referrer-Policy header in August 2026 — and among those that do, 83.4% choose either strict-origin-when-cross-origin or same-origin, showing that the operators who think about the header mostly get it right.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “1,532,662 responses — 7.7% of Referrer-Policy deployers — explicitly configured a leaky value (no-referrer-when-downgrade or unsafe-url), actively choosing to share more URL data with third parties than a modern browser would share by default.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “The .shop TLD achieves 18.6% Referrer-Policy adoption — nearly five times the global rate of 6.8% — because hosted commerce platforms ship the header as a default to every store tenant.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “72,262 HTTP responses declare the unsafe-url Referrer-Policy value, sharing the complete URL of every page — including query strings and path-embedded tokens — with every third-party server those pages contact.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “Only 6.8% of 120.8 million applicable domains pass the Referrer-Policy quality check in the August 2026 census — making it one of the most common, and cheapest to fix, security and privacy gaps on the web.” — defaults.exposed August 2026 Domain Security Census (432M domains)
FAQ
What percentage of websites set a Referrer-Policy header? 8.6% in our August 2026 census — 19,983,630 of 231,968,605 HTTP responses examined. The remaining 91.4% send no policy and inherit whatever the visitor’s browser does by default. Under our stricter methodology check, which requires an effective protective policy, the pass rate is 6.8%.
What is the best Referrer-Policy value to use?
For most sites, strict-origin-when-cross-origin: full URLs stay within your own site, other sites see only your bare origin. It is also what current Chrome and Firefox default to (industry knowledge), so setting it costs nothing in functionality. If you want other sites to learn nothing at all, same-origin or no-referrer — 44.1% of sites that set the header already choose one of those two stricter options.
If browsers now default to a safe policy, does the header still matter? Yes, for three reasons. Older browsers, webviews and non-browser clients don’t all apply the modern default. Anything stricter than the default — same-origin, no-referrer — only happens if you declare it. And an explicit header is a documented decision about personal-data flow, which matters the moment anyone asks how your site handles visitor privacy.
Is unsafe-url ever legitimate? Occasionally — some analytics and affiliate setups want full referrer URLs passed downstream, and the value exists for them. But it shares complete URLs, query strings included, with every third-party server your pages contact. 72,262 responses in our census declare it. If yours is one and you can’t name the system consuming those URLs, that’s a config fossil worth removing.
Does a missing Referrer-Policy header affect a site’s security grade? In our methodology it’s one of the graded checks, with 6.8% of the 120.8 million applicable domains passing as of 2026-08-16. It’s a small weight next to TLS or email authentication, but it is among the most common gaps — and the single cheapest to close. How the checks combine is described in how we graded the internet.
What should I do to set Referrer-Policy on my site?
Add one response header to your web server, CDN, or framework configuration. The value strict-origin-when-cross-origin is safe for virtually every site, costs no functionality, and matches what modern browsers already do — so you are documenting the existing behaviour rather than changing it. If your organisation handles sensitive URL data (account paths, search queries, session identifiers in URLs), consider same-origin or no-referrer for stronger protection. Check whether your existing configuration already sends the header (our free scan shows this), and verify that no-referrer-when-downgrade or unsafe-url are not present unless deliberately configured.
How does Referrer-Policy adoption compare to the July 2026 census? August 2026 is the immediately following measurement after July 2026. The 91.4% no-header figure and 6.8% check-pass rate reflect the state at 16 August 2026. Referrer-Policy adoption is platform-driven rather than operator-driven, as shown by .shop’s 18.6% rate versus .xyz’s 3.7% — improvement happens through hosting platforms defaulting the header, not through individual site operators acting.
Does Referrer-Policy matter for GDPR compliance? Under GDPR, sharing personal data with third-party processors requires a legal basis and documentation. Full referrer URLs containing personal data — account paths, search queries, path-embedded tokens — shared with analytics or advertising processors are personal data transfers. An explicit Referrer-Policy limits what is shared, which both reduces the data flow and documents the organisational decision. This is context, not legal advice.
See where your own domain stands
Check your domain free at defaults.exposed — see whether your domain sets a Referrer-Policy header, what value it declares, and whether it passes our privacy protection check. Takes 30 seconds. No account needed. Read the flagship State of Domain Security 2026 report.
Aggregate data only. Data stored and processed in the EU.
How to cite this report
Press / blog: defaults.exposed (2026). Referrer-Policy: the Privacy Header 91% of the Web Forgot. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/referrer-policy-the-privacy-header-the-web-forgot
Academic: defaults.exposed. (2026, August 18). Referrer-Policy: the Privacy Header 91% of the Web Forgot. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/referrer-policy-the-privacy-header-the-web-forgot
In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=231,968,605 HTTP responses)
About the defaults.exposed August 2026 Census
The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.
Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026