The HTTP Referer header (intentionally misspelled) is an optional field that identifies the address of the previous web page from which a user followed a link. For marketers and SEO practitioners, it is the primary mechanism browsers use to tell your analytics tools where traffic originated. However, modern privacy defaults increasingly limit the data shared, making it essential to understand what you are actually seeing in your logs.
What is HTTP Referer?
The Referer header contains the absolute or partial address (URI or IRI) from which a resource was requested. When a user clicks a hyperlink, the browser sends this header to the new server to indicate the last page visited. This allows servers to identify referring pages for promotional or statistical purposes.
[The misspelling "Referer" originated in a proposal by computer scientist Phillip Hallam-Baker and was permanently established when incorporated into the RFC 1945 standard in May 1996] (Wikipedia). While "referrer" is the correct English spelling, the HTTP specification uses "Referer," though modern related standards like the Referrer-Policy header use the proper spelling.
The header may contain an origin (domain), path, and query string, depending on the active referrer policy. It never includes URL fragments (hash values) or username password combinations. Browsers determine what to send based on the referring page's Referrer-Policy and the destination's security properties.
Why HTTP Referer matters
Referrer data directly impacts how accurately you can attribute traffic sources in analytics platforms.
- Traffic attribution. Without referrer data, visits appear as "direct" traffic in analytics, breaking your ability to measure campaign performance or organic search results.
- Privacy compliance. Referrers can leak sensitive information such as internal search queries or session IDs to third parties, creating regulatory risks.
- Security exposure. Referrer data may expose non-public URLs or internal content paths to external servers, potentially revealing site structure or restricted resources.
- Data availability changes. [As of March 2021, Chrome, Chromium-based Edge, Firefox, and Safari default to sending only the origin (domain name) in cross-origin requests, stripping paths and query strings] (Wikipedia). This shift significantly reduces the granularity of referrer data available to marketers.
How HTTP Referer works
When a browser requests a resource, it follows a specific decision process to determine what referrer information to include.
- Policy check. The browser examines the
Referrer-Policyset by the referring page via HTTP header or meta tag. - Origin analysis. The browser compares the origin of the referring page against the destination (cross-origin vs. same-origin).
- Security evaluation. If the user navigates from HTTPS to HTTP, browsers strip the referrer entirely to prevent data leakage over insecure connections.
- Header transmission. The browser includes the allowed referrer data in the
Refererrequest header sent to the destination server.
You can access the same referrer information on the client side using document.referrer in JavaScript. This property is read-only and returns an empty string for direct traffic, allowing you to customize page content based on traffic source while preventing manipulation.
Best practices
Set an explicit Referrer-Policy. Define your policy using either an HTTP header or a meta tag in your HTML head: <meta name="referrer" content="strict-origin-when-cross-origin">. This ensures predictable behavior across browsers rather than relying on changing defaults.
Use strict-origin-when-cross-origin for balanced data. [Chrome 85 and later versions use this as the default policy, which sends the full URL for same-origin requests but only the origin for cross-origin requests, and sends no referrer when downgrading from HTTPS to HTTP] (Medium). It preserves internal analytics while protecting user privacy externally.
Apply rel="noreferrer" for specific links. When linking to external sites where you do not wish to pass any referrer data, add this attribute to the anchor tag. This overrides the page-level policy for that specific link.
Do not rely on referrer data alone for attribution. Because modern browsers strip query parameters from cross-origin referrers and block them entirely in some scenarios, use UTM parameters or dedicated campaign tracking IDs instead of parsing referrer URLs for source information.
Monitor your logs for referrer spam. Some bots send fake referrer headers containing advertising URLs or malicious domains to appear in your statistics. Filter your analytics to exclude known spam domains that appear in referrer reports.
Common mistakes
Mistake: Assuming you will receive the full referring URL including search query parameters from external sites. Fix: Accept that [modern browsers default to origin-only for cross-origin requests as of March 2021] (Wikipedia). You will see "https://www.google.com/" but not the specific search terms.
Mistake: Using referrer checks to secure content or prevent deep linking. Fix: Never use referrer validation as a security mechanism. The header is easily spoofed by bots and privacy tools. Use authentication tokens or signed URLs instead.
Mistake: Allowing traffic to downgrade from HTTPS to HTTP and expecting referrer data. Fix: Browsers strip referrers when moving from secure to insecure connections. Ensure all destination pages use HTTPS to maintain referrer continuity.
Mistake: Confusing the HTTP Referer header with the Origin header. Fix: The Origin header is sent with POST requests and contains only the scheme, host, and port, without the path. It is designed for security checks, not analytics tracking.
Examples
Example scenario: Search engine visit. A user searches for your brand on Google and clicks your result. With default browser settings, your server receives Referer: https://www.google.com/. You know the traffic came from Google, but the specific search query is not included in the referrer due to HTTPS and privacy policies.
Example scenario: Internal navigation. A visitor clicks from your blog article at https://example.com/blog/seo-tips to your pricing page. Because this is a same-origin request, your analytics receive the full path: Referer: https://example.com/blog/seo-tips. This allows you to track internal content performance accurately.
Example scenario: JavaScript detection. You want to show a special welcome message to visitors coming from a partner site. You check document.referrer in your JavaScript. If the value includes the partner domain, you display the custom banner. However, if the user arrived via a bookmark or direct URL, the property returns an empty string and you show the default view.
FAQ
Why is it spelled "Referer" instead of "Referrer"?
[The misspelling was introduced by Phillip Hallam-Baker in the original HTTP specification proposal and was permanently established in the RFC 1945 standard published in May 1996] (Wikipedia). Modern web standards like the Referrer-Policy header use the correct spelling, but the original HTTP header retains the typo for backward compatibility.
Why did my referrer data suddenly drop or show only domains? [Major browsers including Chrome, Edge, Firefox, and Safari implemented stricter default referrer policies in March 2021, sending only the origin for cross-origin requests] (Wikipedia). Additionally, increased use of HTTPS and privacy-focused browser extensions reduce referrer availability.
What is the difference between the Referer header and Referrer-Policy?
The Referer header is the data sent by the browser indicating where the user came from. Referrer-Policy is an instruction you set on your pages telling the browser how much of that data to send (full URL, origin only, or nothing at all).
Can I access or modify the referrer in JavaScript?
You can read the referrer via document.referrer, which is a read-only property of the document object. You cannot change this value to spoof the referrer for server requests.
Why do some visitors have no referrer data? Direct traffic (bookmarks, typed URLs, or links from desktop apps) carries no referrer. Additionally, browsers strip referrers when moving from HTTPS to HTTP, when users have enabled privacy settings, or when using tools that blank the header.
