What Information Does a Referrer Reveal When You Click a Link?

When you click a link, the site you visit may receive information about the page you came from in an HTTP header called Referer (yes, that spelling is missing an “r”). What it receives depends on the browser’s referrer policy, the relationship between the two sites, and whether the page URL contains sensitive details.

This guide explains what a referrer can reveal, what browsers commonly send, and how site owners and visitors can limit unnecessary sharing.

Key Takeaways

• A referrer identifies the page that initiated a request; it is not a record of your entire browsing history.
• A page URL can contain a path and query string as well as a hostname. Those parts may be sensitive.
• Under the commonly used strict-origin-when-cross-origin policy, a request to another site usually includes only the source site’s origin—not its path or query. Same-origin requests can include the full page URL.
• Site owners can set a Referrer-Policy response header. Visitors can use browser privacy controls, but they cannot make every site or request behave identically.

What the Referer header tells a site

When a browser makes a request, it may include a Referer header containing the URL of the page that initiated that request. The destination server can record the header in its logs. Page scripts may also be able to read referrer information through browser APIs, subject to the applicable policy.

A referrer is not necessarily the page you think of as “the last page I visited.” It describes the page associated with a particular request. A page can make requests for images, scripts, or other resources as well as links you click, and policy rules apply to those requests too.

A URL has several parts. For example:

https://shop.example/account/orders?campaign=spring

Here, https://shop.example is the origin; /account/orders is the path; and ?campaign=spring is the query string. A site URL might include private or identifying information in either the path or query string—for example, an account identifier, search terms, or a password-reset token. Avoid putting secrets in URLs: URLs can be exposed through more channels than referrer headers, including logs and copied links.

The fragment, such as #details, is not sent in the HTTP request’s referrer. Usernames and passwords embedded in a URL are also removed. These facts do not make it safe to put sensitive data in the remaining parts of a URL.

When does the destination receive the full page URL?

The browser’s referrer policy determines how much of the initiating page’s URL is sent. A widely used modern default is strict-origin-when-cross-origin, though browser settings, extensions, and a site’s own policy can affect behavior.

With that policy:

For example, suppose the page is https://shop.example/orders?customer=42 and you follow a link to https://news.example. With the policy above, the destination ordinarily receives https://shop.example/, not /orders?customer=42. A request to another page on shop.example can receive the fuller URL.

Other policies can send more or less. no-referrer sends no referrer. origin sends only the origin. unsafe-url can send the full URL even to a different site or an insecure destination, so it can expose more information than intended. Treat policy names and outcomes as rules for browser requests, not guarantees that a destination will use or retain the information in a particular way.

How site owners can choose a policy

For most sites, an explicit response header is a practical way to set a site-wide policy:

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

This generally preserves origin-level information for cross-site analytics or troubleshooting while withholding paths and query strings from other origins. If even the origin should not be shared, consider no-referrer; check whether that affects features or analytics you rely on. Avoid unsafe-url unless you have a specific, reviewed reason to disclose full URLs.

A page can also declare a policy in HTML:

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

For an individual link, use referrerpolicy when that link needs a different setting:

<a href="https://partner.example/" referrerpolicy="no-referrer">
  Visit the partner site
</a>

The noreferrer link relation is another option when you want that link to omit referrer information:

<a href="https://partner.example/" rel="noreferrer">
  Visit the partner site
</a>

Choose deliberately: suppressing referrers can reduce attribution data for the destination. Also, a referrer policy is not a substitute for keeping secrets out of URLs or protecting access with authentication and authorization.

What visitors can do

• Use browser privacy settings or reputable extensions that restrict referrer sharing. Their behavior can vary by browser and configuration.
• Avoid putting personal information, access tokens, or other secrets in URLs you share or visit. If a site exposes a secret in a URL, contact the site owner and treat the secret as potentially exposed.
• Be cautious when sharing a link copied from a page: the link itself may contain sensitive information, regardless of the referrer policy.
• Remember that private browsing, a VPN, or clearing history does not by itself remove a referrer from a request. Those measures address different privacy concerns.

A visitor may not be able to override a policy in every browser or for every request. Site owners control the policy their pages declare, and browser tools may apply their own rules. A referrer restriction also does not hide other information a destination may receive, such as the request’s IP address or data you submit directly.

Common Mistakes

• Assuming the destination always sees the complete previous URL. Cross-origin requests under common policies typically reveal less than same-origin requests.
• Assuming a query string is harmless. Query parameters and paths can contain personal details or secrets, especially when URLs are logged or shared.
• Treating a referrer as proof of identity or authorization. Requests can be made by software that sets headers itself. Do not use Referer as an access-control mechanism.
• Assuming a privacy tool removes every trace. Referrer controls affect one kind of information; they do not make browsing anonymous.
• Setting no-referrer without checking consequences. Some analytics and attribution workflows depend on referrer information.

Best Practices

• For site owners: Set an explicit Referrer-Policy response header appropriate to your privacy and measurement needs. Review sensitive pages and avoid placing secrets in URLs.
• For links to third parties: Use a per-link policy such as referrerpolicy="no-referrer" when the destination does not need source information.
• For developers: Test both same-origin and cross-origin requests, including secure-to-insecure cases, using the browser’s network tools.
• For visitors: Treat URLs as shareable data. Check the address before copying or posting a link, and use browser privacy controls as one layer rather than a complete privacy solution.

Research note: I could not retrieve current browser documentation or the live web platform specification in this environment. The behavior described here is qualified accordingly; consult the relevant browser documentation and Referrer Policy specification when making version-specific implementation decisions.

Conclusion

A referrer can reveal the page that led to a request, but the amount ranges from no information to a page URL containing a path and query string. A deliberate site policy, careful URL design, and sensible visitor privacy controls can reduce unnecessary disclosure without treating referrer settings as a complete privacy or security measure.