When you follow a link, the destination often learns where the request came from. That clue travels in an HTTP header with the historically misspelled name Referer. It helps websites understand traffic, debug broken journeys, and apply security checks. It can also reveal more context than a visitor expects.
Modern browsers limit that information by default. Website owners can narrow it further through referrer policy. Knowing the boundary makes privacy claims easier to judge.
What a referrer header reveals
A referrer can contain the address of the page that initiated a request. If you move from one page to another on the same site, the full path and query may be available. When you cross to a different origin, current browser defaults usually reduce the value to the origin: the scheme, host, and port.
That distinction matters. An origin such as https://example.com/ identifies the site. A full address such as https://example.com/account/reset?token=... may expose a sensitive route or badly designed query parameter.
MDN’s Referrer-Policy reference documents each policy and notes that strict-origin-when-cross-origin is the current default when a site does not specify another valid value.
Links are not the only source
The header can accompany more than a top-level navigation. A page may request an image, stylesheet, script, font, analytics endpoint, or embedded frame from another origin. The recipient can then learn which site caused that resource request, subject to the active policy.
This is useful for operations. A publisher can see which article sends readers to a subscription page. A service can identify unexpected use of an image. A security team can investigate the path into a sensitive workflow.
The same signal can feed cross-site measurement. A third-party resource present across many pages can combine referrer information with cookies, IP addresses, or browser characteristics. Tracker blocking and referrer limits therefore solve related but different problems.
Why browsers shortened cross-site referrers
Older behavior often sent the complete referring URL across secure sites. That created needless exposure when addresses included search terms, document identifiers, internal paths, or personal data placed in a query string.
The modern default keeps the full referrer for same-origin requests, sends only the origin to another secure origin, and omits the header when navigating from HTTPS to a less secure HTTP destination. It preserves useful site-level attribution without routinely sharing the exact page path across sites.
This default is a compromise, not anonymity. The destination still sees its network connection and may receive the source origin. It can also learn context from tracking parameters embedded directly in the link. Our guide to tracking parameters in URLs explains that separate channel.
What website owners can control
A site can send the Referrer-Policy response header, declare a policy in HTML, or set a policy on individual links and resources. The available choices range from no-referrer, which omits the header, to unsafe-url, which can send a full address much more broadly.
MDN’s practical referrer-policy guide recommends choosing the strictest policy that still supports the site. For many public sites, the browser default is a reasonable starting point. Sensitive services may prefer same-origin or no-referrer.
Individual external links can use rel="noreferrer". Developers should test carefully because removing the referrer may change analytics, affiliate attribution, fraud detection, or flows that incorrectly depend on the header.
Do not put secrets in a URL
Referrer policy reduces exposure, but it should never carry the full burden of protecting sensitive values. URLs appear in browser history, server logs, screenshots, copied messages, support tickets, and analytics systems. Tokens, email addresses, medical details, and private document names do not belong in query strings when safer designs exist.
A well-designed service uses short-lived identifiers, appropriate request bodies, secure cookies, and authorization checks. It also avoids treating the referrer as proof that a request is trustworthy. Headers can be absent, stripped by privacy tools, or produced by contexts the application did not anticipate.
Private browsing does not erase referrers
A private window mainly limits what remains on the device after the session. It does not make every request anonymous, and it does not guarantee that destination sites receive no referrer. The same browser and page policies still govern most network behavior.
Our guide to what private browsing keeps private separates local history protection from network privacy. For the wider request picture, see what a browser sends before a page loads.
Practical steps for readers
- Read the destination domain before following sensitive links.
- Remove unnecessary campaign parameters before sharing an address.
- Avoid placing personal information in URLs, even on trusted sites.
- Use tracker blocking to limit third-party requests that can receive referrer data.
- Keep the browser updated so current privacy defaults and security fixes apply.
Browser extensions that rewrite headers deserve caution. Broad access to every page is a large permission for a small change, and incorrect rules can break sign-in, payments, or security checks.
The referrer header is a small piece of web infrastructure with an outsized effect on context. Modern defaults reveal less than they once did, but the cleanest privacy design remains simple: share only the context a destination genuinely needs, and never place secrets in an address.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.