Understanding Referrer Headers and Link Privacy

By cryptoke, developer and editor at SafeLinkWrite. Reviewed for technical accuracy.

Every time you click a link, your browser sends a small piece of metadata to the destination. It is called the referrer header. It tells the destination which page you came from. It is invisible on the page, included by default, and it leaks more information than most visitors realize. For a private forum, a mail archive, or a members-only thread, that leak can reveal more about the reader than the reader intends. For a site owner, it is one of the easiest metadata leaks to close — with one HTTP header, one HTML attribute, or one intermediate page.

This guide explains what the referrer header carries, why it matters, what modern browser defaults actually send, and how a safelink can absorb the leak without breaking the navigation.

What the Referrer Header Contains

The referrer header is a text string attached to every outbound request. It contains information about the page you were on when you clicked. In older versions of the standard, that meant the full URL — scheme, host, path, and query string. In modern browsers, the amount of information is trimmed by default for cross-origin requests, but the origin domain — and often the path — still travels.

Two examples:

• Clicking from https://forum.example.com/thread-12345 sends the destination a referrer of https://forum.example.com/ under modern defaults, or the full thread URL under legacy configurations.
• Clicking from https://mail.example.com/inbox/msg-998877 sends approximately the same truncated referrer, or nothing at all, depending on the mail service's policy.

The destination now knows where the visitor was. If the source page is identifiable — a specific thread, a specific search URL — the destination learns something about the visitor's context.

Why Referrer Leakage Matters

The referrer header is one of the primary inputs to analytics platforms. When a site sees traffic from a specific subreddit, tweet, or private forum, it can record that the reader came from there. Over time, the destination builds a picture of where its audience originates.

For public pages, this is usually harmless. For private contexts — a members-only forum, a mailing list archive, a chat application with a web view — the leak can reveal more than the visitor realizes. Every link clicked from such a page tells the destination the name of that page.

A second dimension matters even more. The referrer reveals not just where the visitor came from, but that the page exists and was visited. If two people click the same link from the same private thread, the destination sees two visits from the same referrer — which hints at the thread's existence, size, and reach.

Technical Breakdown: Referrer Policy Options

Modern browsers have tightened default behaviour. Chrome, Firefox, and Safari now default to strict-origin-when-cross-origin: full URL for same-origin requests, origin-only for cross-origin HTTPS, and no referrer for HTTPS→HTTP downgrades. This is a meaningful improvement over the older default that sent the full URL cross-origin.

Site owners can override the default with the Referrer-Policy HTTP header, the HTML <meta> tag, or the referrerpolicy attribute on individual anchors.

Policy	Same-origin	Cross-origin (HTTPS→HTTPS)	Cross-origin (HTTPS→HTTP)
no-referrer	Nothing	Nothing	Nothing
same-origin	Full URL	Nothing	Nothing
strict-origin	Origin only	Origin only	Nothing
strict-origin-when-cross-origin (default)	Full URL	Origin only	Nothing
unsafe-url	Full URL	Full URL	Full URL

In most cases, the correct choice for a public-facing site is the default: strict-origin-when-cross-origin. For private pages, a stricter policy such as same-origin or no-referrer is appropriate.

Example: What Actually Travels on a Click

Suppose a reader is logged into a members-only forum and clicks a link to an external article from this page:

https://forum.example.com/private/thread-7712?t=secret

What the destination receives depends on the source page's policy:

Source policy	Referrer sent to destination
unsafe-url	https://forum.example.com/private/thread-7712?t=secret
strict-origin-when-cross-origin (default)	https://forum.example.com/
same-origin or no-referrer	(empty)

The middle row is what most modern browsers actually send by default. It is better than the first row, but it still confirms to the destination that the visitor arrived from forum.example.com. For a subscription forum whose existence is itself sensitive, that is still a leak worth closing.

Mitigations for Site Owners and Visitors

From the perspective of a site owner:

• Set Referrer-Policy: strict-origin-when-cross-origin as a baseline, or stricter for private sections.
• Add rel="noreferrer" to links on private pages. This instructs the browser not to send a referrer for that specific link, regardless of page-level policy.
• Add rel="noopener" alongside noreferrer for external links — the browser will not give the destination a reference to your page's window object.
• Audit hosted libraries, embedded widgets, and third-party scripts, which can send their own referrer-bearing requests.

From the perspective of a visitor:

• Check the browser default. Most modern browsers already meet strict-origin-when-cross-origin or better.
• Use an extension that enforces a stricter global referrer policy if you routinely navigate from private pages.
• Assume every click sends the domain of the source page — even when the path and query string are stripped.

Myths vs Facts

Myth	Fact
"HTTPS hides the referrer."	HTTPS encrypts the request in transit but does not remove the referrer header. The destination still reads it.
"Incognito mode strips the referrer."	Incognito prevents persistence of the visit locally. It does not alter what is sent in the request itself.
"Only the origin is ever sent, so nothing useful leaks."	Origin alone identifies the site. For a private forum, that is often the sensitive part.
"Removing the referrer breaks analytics."	It reduces attribution data for the destination. For a private source, that is the point.
"A safelink adds tracking instead of removing it."	A properly built safelink absorbs the referrer and can forward with an empty one. A poorly built safelink can log the visitor. The design, not the pattern, decides.

Safelinks and Referrer Privacy

A safelink is an intermediate page. When a visitor reaches it, the referrer of the original page is sent to the safelink — not to the destination. When the visitor is forwarded to the destination, the referrer of the safelink page is sent, and that page can enforce a stricter policy than the original source.

The result: the destination sees the visitor, but no longer sees the original source domain. The safelink sits between the two and absorbs the passive leak.

To make this work correctly, three conditions must hold:

1. The safelink page sets Referrer-Policy: no-referrer (or sends rel="noreferrer" on the outgoing redirect anchor).
2. The safelink page does not log or store incoming referrer values.
3. The safelink page skips third-party scripts that would send their own referrer-bearing requests back to an ad network.

If any of those three fail, the safelink becomes a middleman that sees what it was supposed to hide. That is the difference between a privacy-improving safelink and a tracking one — same pattern, different design.

Practical Steps

1. Audit your site's referrer policy. Check the HTTP response header or the <meta name="referrer"> tag. If neither is set, the browser default applies.
2. Add rel="noreferrer" to outbound links from private or login-gated pages. This is the single most effective per-link control.
3. Apply a stricter policy to sensitive sections. Set Referrer-Policy: no-referrer on members-only or archived-section responses.
4. If you operate a safelink, verify it strips the incoming referrer before forwarding. Inspect the outgoing request in DevTools → Network to confirm the Referer field is absent.
5. Test with real navigation. Load a private page, click an outbound link, and inspect the outgoing request. What travels is what leaks.

Conclusion

The referrer header is a modest piece of metadata — not a credential, not a cookie, not a fingerprint. Its significance comes from three properties: it is sent automatically, it is included by default, and it reveals context that the visitor may not have considered. The countermeasures are equally simple: a header on the server, an attribute on the anchor, or an intermediate page that absorbs the leak instead of forwarding it. Understanding the referrer is the first step toward deciding what to send, what to strip, and what to route through a safelink that actually delivers the privacy it promises.