Referer general request

What it does

Referer tells the server which URL the user came from — the page that contained the link or form that triggered the current request. A user clicking a link on https://search.example.com/results?q=cats to https://yoursite.com/cats would send:

Referer: https://search.example.com/results?q=cats

Servers use this for analytics (tracking traffic sources), access control (hotlink protection), and security (CSRF detection).

Syntax

Referer: <url>

A single absolute URL — the address of the page that initiated the request:

Referer: https://www.google.com/search?q=developer+tools
Referer: https://docs.example.com/guides/getting-started
Referer: https://reddit.com/r/webdev

When browsers send (and don't send) Referer

Sent:

• User clicks a link on a page
• Page loads a resource (image, script, font) from another origin
• Form submission

Not sent (browser suppresses or limits it):

• Direct navigation (typing URL, bookmarks, address bar)
• Navigation from HTTPS to HTTP (downgrade — the default strict-origin-when-cross-origin policy strips the full URL)
• Referrer-Policy: no-referrer on the source page
• Private/incognito mode (browsers vary)
• Local files (file://)

The exact behaviour depends on the Referrer-Policy set by the referring page.

Analytics use case

Referer is how analytics tools know where your traffic came from:

• Referer: https://google.com/... → organic search
• Referer: https://twitter.com/... → social media
• Referer: https://partner-site.com/... → referral traffic
• No Referer → direct traffic (or privacy-suppressed)

This is why significant traffic appearing as "direct" in analytics can actually be suppressed referrers from HTTPS-to-HTTP transitions or no-referrer policies.

Hotlink protection

Servers use Referer to prevent hotlinking — other sites embedding your images or files directly, consuming your bandwidth without users visiting your site:

# nginx hotlink protection
valid_referers none blocked server_names *.example.com;
if ($invalid_referer) {
    return 403;
}

none allows direct access (bookmarks, address bar). blocked allows requests where Referer is present but stripped by a proxy. Only requests with a Referer pointing somewhere other than your own domain are blocked.

Limitations: Hotlink protection via Referer is easily bypassed by not sending the header at all (curl, wget, or any client can omit it). It deters casual hotlinkers but not determined ones.

CSRF detection

Some applications check Referer as a CSRF mitigation — if the Referer doesn't match your own domain, the request might be a cross-site attack. This is a weak defense:

• Legitimate requests from bookmarks or direct navigation may have no Referer
• The check can cause false positives for privacy-protected browsers
• CSRF tokens are the proper mitigation; Referer is only a supplementary signal

The famous typo

The header name Referer has a typo — it should be "Referrer" (two r's). Tim Berners-Lee misspelled it in the original HTTP specification (RFC 1945, 1996), and it's been wrong ever since. The W3C created Referrer-Policy (correct spelling) which coexists with the misspelled Referer header in the same HTTP ecosystem. It will never be fixed — too much code depends on the typo.

How it interacts with Referrer-Policy

Referrer-Policy on the source page controls how much URL information is included in Referer when users navigate away:

Common mistakes and gotchas

Relying on Referer for security. It's easily spoofed — any HTTP client can set Referer to any value. Use CSRF tokens for CSRF protection, not Referer checks.

Logging Referer without sanitisation. Referer values can contain sensitive user data from the referring URL's query string (search terms, tokens). Scrub or hash Referer values in logs before storing.

Hotlink protection breaking CDN or social previews. Social media crawlers and CDN preloaders don't always send a Referer matching your domain. Overly strict hotlink protection blocks these legitimate requests. Test thoroughly.

Real-world examples

Organic search click:

GET /blog/post HTTP/1.1
Host: example.com
Referer: https://www.google.com/search?q=http+headers+reference

Internal page navigation:

GET /about HTTP/1.1
Host: example.com
Referer: https://example.com/

Resource request (script loading):

GET /scripts/app.js HTTP/1.1
Host: cdn.example.com
Referer: https://app.example.com/dashboard

No Referer (direct navigation):

GET / HTTP/1.1
Host: example.com

FAQ

Is Referer sent for HTTPS resources loaded by HTTPS pages?

Yes — by default (with strict-origin-when-cross-origin), but only the origin is sent, not the full URL path. So loading a script from https://cdn.example.com/app.js on https://yoursite.com/page?data=sensitive sends Referer: https://yoursite.com — not the full URL with the query string.

Can I suppress Referer for specific links?

Yes — use the referrerpolicy attribute on the <a> element:

<a href="https://external.com" referrerpolicy="no-referrer">Click</a>

This overrides the page-level Referrer-Policy for just this link.

Does Referer contain the full URL including query strings?

Depends on Referrer-Policy. With the default strict-origin-when-cross-origin, cross-origin requests only get the origin. Same-origin requests (navigating within your site) get the full URL. Use no-referrer or strict-origin if you never want query strings shared.

Fun fact

The Referer typo is arguably the most famous bug in web standards history. Tim Berners-Lee has acknowledged the mistake. Multiple proposals to add a correctly-spelled alias (Referrer) have been discussed and rejected over the decades — the consensus being that maintaining two spellings for the same header would cause more confusion than the original typo. So the misspelling is now formally correct, and the correct spelling Referrer-Policy stands beside it as the new standard — two spellings coexisting for the same concept in the same ecosystem, forever.