Tags: web-dev analytics concept

Referrer Policy

Date: 2026-08-17

---

What the browser tells the next site about where you came from. The default changed years ago to send only the origin cross-site — which quietly broke a lot of attribution, leaked less, and is still misdiagnosed as a tracking bug when analytics shows traffic arriving from nowhere.

---

Referrer policy is the browser setting — per document, element or response header — that controls how much of the current page’s URL is sent in the Referer header of outgoing requests.

What gets sent

The Referer header — misspelled in the original specification and permanently so — carries the URL of the page the request came from.

FULL URL SENT                        ORIGIN ONLY

Referer: https://blog.example.com    Referer: https://blog.example.com/
  /2026/best-winter-coats
  ?utm_source=newsletter

→ you know the exact article         → you know only the site
→ and any query parameters,          → path and query stripped
  which may contain personal data

The modern default is strict-origin-when-cross-origin, which means:

same-origin navigation      → full URL
cross-origin, HTTPS→HTTPS   → origin only          ← the common case
HTTPS → HTTP (downgrade)    → nothing at all

The policies

Value	Same-origin	Cross-origin	Downgrade
no-referrer	Nothing	Nothing	Nothing
origin	Origin	Origin	Origin
strict-origin	Origin	Origin	Nothing
same-origin	Full URL	Nothing	Nothing
strict-origin-when-cross-origin	Full URL	Origin	Nothing
no-referrer-when-downgrade	Full URL	Full URL	Nothing
unsafe-url	Full URL	Full URL	Full URL

strict-origin-when-cross-origin is the default and the right choice for almost everyone — full detail internally, origin only externally, nothing on a protocol downgrade.

unsafe-url is named as a warning. It leaks your full URLs, including any parameters, to every site you link to. If a URL ever contains an order ID, an email address, a reset token or a session identifier, that value is now in a third party’s server logs — PII in Analytics, Common Vulnerabilities.

Setting it

<!-- page-wide -->
<meta name="referrer" content="strict-origin-when-cross-origin">

Referrer-Policy: strict-origin-when-cross-origin

<!-- per link, which overrides the page policy -->
<a href="https://partner.example.com" referrerpolicy="no-referrer">…</a>
 
<!-- per resource -->
<img src="https://cdn.example.com/x.jpg" referrerpolicy="origin">

The HTTP header is preferable to the meta tag — it applies to requests made before the parser reaches the tag, which the meta version can’t.

What it breaks, and how that reads in analytics

This is where it matters commercially. Losing the path means losing the detail behind a referral.

BEFORE (full referrer)               NOW (origin only)

Source: blog.example.com             Source: blog.example.com
Path:   /best-winter-coats           Path:   /
Campaign: newsletter                 Campaign: —

→ "the coat article drove £40k"      → "the blog drove £40k"

And when the referrer is stripped entirely — a downgrade, a no-referrer policy on the sending site, or a redirect through an intermediary that drops it — the visit lands in direct traffic, which is where unattributed sessions go to be misread as brand strength — Direct Traffic and Lost Referrers, Channel Taxonomy.

The correct response is not to loosen your policy. You control what your site sends, not what sites linking to you send — so relaxing yours leaks your data without recovering theirs. The fix is to stop depending on the referrer:

• UTM parameters on every link you control — campaigns, partner links, email, affiliates. They survive everything the referrer doesn’t — UTM Governance
• Click identifiers from ad platforms, captured on landing and persisted first-party — Server-Side Conversion APIs
• Treat the referrer as a fallback, not a source of truth — Attribution Models

Where the policy is set for you

Things that strip or alter the referrer regardless of your configuration:

• The linking site’s own policy. Most large platforms send origin-only or nothing
• Native apps opening links in an in-app browser, frequently with no referrer
• Email clients, where a click may arrive with no referrer at all
• Redirect chains. Each hop can drop it, and link shorteners and affiliate trackers routinely do — Redirects and Link Equity
• Privacy browsers and extensions stripping it outright — Ad Blockers and Tracking Loss

Practical

• Set strict-origin-when-cross-origin explicitly rather than relying on the default. Defaults vary by browser version and being explicit costs one header
• Audit URLs that could carry sensitive values. Password reset tokens, order confirmations, unsubscribe links — anything with a secret in the query string should be on a page with no-referrer
• rel="noreferrer" also implies noopener, which is a security control against tab-nabbing — useful, and a separate concern to conflate deliberately rather than by accident
• Check what your outbound links leak before assuming the default protects you — a referrerpolicy set to something permissive on a single component is easy to miss

Where it interacts

• Direct Traffic and Lost Referrers — the analytics symptom this produces, and how to diagnose it
• UTM Governance — the mechanism that survives referrer loss
• Browser Privacy Restrictions — the broader programme this default change is part of
• Content Security Policy — the other header-set policy layer, often configured alongside