Referrer policy: what your links tell the destination

What the header carries and who sees it

When a browser follows a link, it may send a Referer header telling the destination which page the request came from. The destination site sees it, and so does anything embedded in that destination page that receives the referrer in turn. It is the mechanism behind most of what analytics tools call traffic sources, and it is entirely under the control of the originating page rather than the destination.

The header carries a URL, and URLs frequently contain more than a page identity. Search terms, internal identifiers, tokens in a path, filter state, sometimes a session parameter that should never have been in a URL at all. Whatever is in the address bar is what may be handed to the next site.

The default in modern browsers is already a compromise

Browsers now default to sending the origin only when a request crosses to a different site, and the full URL when navigating within the same site. Cross-origin navigations therefore reveal the host you came from but not the path or the query string. This default was chosen precisely because full-URL leakage across sites was causing real disclosure problems.

It has a consequence people notice in analytics: an external site can see that traffic came from your domain, but not from which page. If your reporting depended on path-level referrer detail from other people's sites, it stopped working when this default landed, and no amount of configuration on your side will bring it back.

The policies worth knowing

Several values are available. No referrer sends nothing at all. Origin sends only the scheme and host. Same-origin sends the full URL internally and nothing externally. Strict origin when cross origin, the common default, sends the full URL internally and the origin externally, and sends nothing when moving from a secure page to an insecure one. Unsafe URL sends everything always, and the name is a fair warning.

Set the policy with a meta tag in the page head or with a response header, and you can override it on an individual link with an attribute. That per-link override is the useful tool: it lets you keep a sensible site-wide default and be stricter on the specific links where the current URL contains something you would rather not hand over.

How a redirect service sits in the middle

A short link is an intermediate hop, which means the referrer the destination eventually sees depends on the policy of the page the person clicked from, on what the redirect service does, and on the scheme of each hop. A redirect can pass the original referrer through, replace it with itself, or strip it entirely.

This is worth checking rather than assuming, because it directly determines what appears in the destination site's reports. Traffic that shows as direct, when you know it came from a specific campaign, very often means the referrer was dropped somewhere in the chain. That is a good reason to rely on explicit campaign parameters instead of on referrer inference.

Referrer is a weak identifier and a real leak at the same time

For analytics it is unreliable: it disappears on HTTPS to HTTP transitions, it is stripped by privacy tooling, it is absent from many app-embedded browsers, and its content is being progressively reduced by browser vendors. Building measurement on it means building on something that erodes.

For privacy it is still meaningful, because the cases where it does leak are exactly the cases where the URL contained something specific. Both statements are true simultaneously, which is why the answer is to stop depending on it for measurement and to constrain it for privacy.

Keep secrets out of URLs, which is the real fix

Referrer policy limits the damage from identifiers in URLs, but it does not eliminate it. Those URLs also appear in browser history, in server logs at every hop, in shared screenshots, in bookmarks and in anything a person pastes into a chat. A token in a query string has many more ways to escape than the referrer header.

If a URL must carry something sensitive, make it short-lived and single-use, and design the destination to exchange it for a proper session immediately. Then a leak through any of those channels is bounded rather than permanent.

Write the policy down and apply it consistently

Decide the site-wide default, decide the exceptions, and record both somewhere the next person will find. The common shape is a strict default with per-link relaxation only where a partner genuinely needs the origin for their own attribution, and a stricter no-referrer setting on pages whose URLs contain identifiers.

Then verify it. Open a page, follow a link to a destination you control, and inspect the header that arrives. Policies set in a template are frequently overridden by a header set at the edge, and the only way to know which one won is to look at the request.