What the referrer header actually contains
When a browser requests a new page after following a link, it can attach a header named Referer to that request, carrying the URL of the page the visitor was just on. A server reading that header can tell, for that one request, where the visitor arrived from. Nothing about this requires the linking page to cooperate; the browser sends it on its own, if it decides to send it at all.
That last clause matters more than it sounds like it should. The browser decides how much of the previous URL to hand over, based on a policy the sending page can set, called Referrer-Policy. A page can choose to send the full URL, only the domain, or nothing. If it never sets a policy at all, every current browser now applies a default on the page's behalf. That default is not full disclosure.
| Referrer-Policy value | What gets sent cross-origin |
|---|---|
| no-referrer | Nothing, ever, regardless of destination |
| origin | Scheme and host only, no path, always |
| strict-origin-when-cross-origin | Full URL on the same origin, origin only across origins, nothing on an HTTPS to HTTP downgrade. This is the modern browser default. |
| unsafe-url | The full URL always, including to HTTP destinations. Rarely used deliberately. |
Referrer vs referer: the spelling that never got fixed
Both spellings describe the same thing. The split is not a disagreement, it is a fossil. When the HTTP/1.0 specification was written in 1996, the header name was typed with a single r, Referer, which is not standard English spelling. By the time anyone noticed, that misspelled header name was already shipping in every browser and server on the internet, and a protocol header cannot be quietly corrected once it is live everywhere. The literal bytes sent on the wire, in every HTTP request ever made, still use the single-r version. The word describing the concept in normal English, in analytics dashboards, and in documentation written after the fact, uses the correct double-r spelling, referrer. You will see both in the wild forever. They are not different things.
Why a referrer often shows only a domain, or nothing at all
This is the part that trips people up most, and it is not a bug in whatever is reading the data. Since browsers moved to a default policy called strict-origin-when-cross-origin, a referrer sent across a domain boundary is trimmed down to just the scheme and host, no path, no query string, unless the sending page explicitly opts into sharing more. A click that came from a specific Instagram post shows up as instagram.com, not the exact post URL. The browser deliberately withheld the rest. That is a privacy default working as designed, not a tracking tool failing to capture something it should have caught.
| Navigation | Referrer sent | What shows up in analytics |
|---|---|---|
| Click from an Instagram or TikTok feed post | Often none at all | Direct, or an app-specific in-app browser referrer |
| Click from Google search results | Origin only, by default policy | google.com, without the search query |
| HTTPS page linking to an HTTP page | None, browsers block it outright | Direct |
| HTTPS page linking to another HTTPS page, default policy | Origin only | Just the domain, no path |
| Typed URL or a bookmark | None, there is no previous page to report | Direct |
| Click inside most email clients | Usually none | Direct |
Notice how many rows end in direct. That single word covers several genuinely different situations, real direct traffic, a stripped in-app browser, an HTTPS downgrade, and a privacy setting, which is exactly why "direct" as a category is worth treating with suspicion rather than taking at face value. The full breakdown of what tends to cause it lives in why is my traffic showing as direct.
Where referrer data still gets used
Before UTM parameters were common practice, referrer was the entire basis for a website's traffic source report, and most analytics tools still fall back to it as the default source when a link carries no UTM of its own. That is why a link posted with no tagging at all still shows up under some source in a dashboard rather than nothing; the referrer, truncated or not, is doing the labeling on its own. It is also why email newsletters specifically tend to rely on UTMs rather than referrer, since most email clients strip the header entirely before a click is even registered. Referrer has nothing left to report from that channel no matter how permissive the policy is.
What a referrer is good for, and where it runs out
A referrer answers one question well. What site, or what page, sent this visitor. It does not answer which specific post, ad, or email did it, because so many real-world paths truncate or drop the header entirely before that detail survives. That gap is exactly what UTM parameters exist to close, since a UTM rides inside the URL itself rather than depending on a header the browser might withhold, and it is why an ad platform's own click ID is a separate mechanism again, built to survive the exact truncation that a referrer cannot. A redirect in between a click and its destination is the other piece worth understanding, since it is the hop where a referrer, a UTM, and a click ID either all survive together or all get quietly dropped, depending on how carefully that redirect was built.
Raydar logs referrer alongside UTM parameters and first touch and last touch cookies on every click a bio page receives, so a truncated or missing referrer on its own does not leave a campaign unexplained; the UTM and cookie data sitting next to it usually fills in what the header could not.