The Spelling Rule Behind Referer vs Referrer

Which spelling is correct, referer or referrer?

The short answer to referer vs referrer is that both spellings are correct, each in its own place: the HTTP request header is Referer, with a single r in the middle, and almost every name coined after it, including document.referrer, the Referrer-Policy header and the referrerpolicy attribute, uses the dictionary spelling. The misspelled form is the header name that travels over the wire. The correct form is what developers type into HTML, JavaScript and response headers.

One test covers most cases. If you are reading or writing the raw request header, or a server variable built from it, write Referer. If you are naming anything else, write referrer. The table further down lists where that test holds and where a framework bends it.

Where did the Referer misspelling come from?

The misspelling entered the written record in RFC 1945, the HTTP/1.0 document by Tim Berners-Lee, Roy Fielding and Henrik Frystyk, dated May 1996. Section 10.13 defines the field without any comment on its spelling:

Referer        = "Referer" ":" ( absoluteURI | relativeURI )
 
Referer: http://www.w3.org/hypertext/DataSources/Overview.html

RFC 1945 was never a standard. Its status note says "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind." The document described HTTP as browsers and servers already ran it, so the header name was in production traffic before anyone wrote it down. Correcting it on paper would have broken every server that already read it.

The first admission came eight months later. RFC 2068, the first HTTP/1.1 specification and the first on the standards track, dated January 1997, opens section 14.37 with "The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.)" RFC 2616 repeated that sentence in June 1999.

The current specification keeps the typo and the confession. RFC 9110, HTTP Semantics, dated June 2022 and published as Internet Standard 97, opens section 10.1.3 with "The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the target URI was obtained (i.e., the "referrer", though the field name is misspelled)." Twenty-six years after RFC 1945, the editors still annotate the name instead of renaming it, because a rename would change the one string every server looks up.

Which names use which spelling?

Every name the web platform added after the header uses the dictionary spelling, and every server-side name built mechanically from the header keeps the typo.

The W3C Referrer Policy draft states the choice in its own grammar notes: "The header name does not share the HTTP Referer header's misspelling." MDN makes the same point on its Referrer-Policy page: "The Referrer-Policy header does not share this misspelling."

The server-side names inherit the typo through a naming rule, not a decision. The PHP manual says PHP creates $_SERVER entries "named HTTP_ followed by the header name, capitalized and with underscores instead of hyphens," so the Referer header arrives as HTTP_REFERER. Django's request reference describes HTTP_REFERER as "The referring page, if any."

Express goes the other way and accepts both. The docblock on req.get in the Express source reads "The Referrer header field is special-cased, both Referrer and Referer are interchangeable," and the code returns this.headers.referrer || this.headers.referer. That order means a request carrying a header literally named Referrer wins over the standard one, which matters only if a client sends the nonstandard name on purpose.

Does the misspelling cause real bugs?

The misspelling causes three bugs that show up again and again in code review, and only one of them is about the missing r.

Header lookups that return nothing. Code that reads a header named referrer from a raw header map gets an empty result, because RFC 9110 defines only Referer and that is the name browsers send. Express hides this by checking both names. PHP and Django expose only HTTP_REFERER.

Trying to set the header from JavaScript. MDN lists Referer as a forbidden request header, so passing it inside fetch() headers does not change what the browser sends. The referrer option on RequestInit exists for that job. MDN documents three kinds of value: "A same-origin relative or absolute URL" sets the header, "An empty string" omits it, and about:client uses the default for the request context, which is the default when the option is absent.

The dash, not the r. MDN warns that "the noreferrer link relation is written without a dash. When you specify the referrer policy for the entire document with a <meta> element, it should be written with a dash: <meta name="referrer" content="no-referrer">." So rel="noreferrer" and content="no-referrer" are both right, and swapping them silently does nothing.

What does document.referrer return?

document.referrer returns the address of the page that linked to the current one, as a string. MDN says "The value is an empty string if the user navigated to the page directly (not through a link, but, for example, by using a bookmark)." MDN's example makes the trimming visible: after a click from an MDN article to w3.org, the property on the new page outputs "the previous domain like developer.mozilla.org", not the full article URL.

That trimming comes from the referrer policy, which also governs the header. The W3C draft says "The default referrer policy is "strict-origin-when-cross-origin"", and MDN describes that policy as: "Send the origin, path, and query string when performing a same-origin request. For cross-origin requests send the origin (only) when the protocol security level stays same (HTTPS→HTTPS). Don't send the Referer header to less secure destinations (HTTPS→HTTP)." Client-side analytics scripts read document.referrer, and server logs read Referer. Under the default policy, both see a hostname for cross-site visits and nothing for a downgrade to HTTP. How that hostname becomes a channel is covered in what counts as referral traffic, and what happens when it is empty is covered in direct traffic.

Where do the specifications disagree?

The specifications disagree in two places, and both affect what an analytics tool can see.

The first is RFC 9110 against the browser default. RFC 9110 says "A user agent SHOULD NOT send a Referer header field if the referring resource was accessed with a secure protocol and the request target has an origin differing from that of the referring resource, unless the referring resource explicitly allows Referer to be sent." The W3C default policy sends the origin on exactly that request, HTTPS page to a different HTTPS origin, with no explicit permission from the page. Both texts are live. Browsers follow the W3C default, which is why referral reports still show hostnames. The two documents agree on the downgrade case, where RFC 9110 says a user agent "MUST NOT send a Referer header field in an unsecured HTTP request if the referring resource was accessed with a secure protocol."

The second is which elements accept noreferrer. Three sources give three lists:

The HTML Standard defines link types, so its list governs: "The noreferrer keyword may be used with a, area, and form elements." MDN's own rel="noreferrer" page agrees with the HTML Standard, which leaves its Referrer-Policy page as the outlier.

For campaign traffic, none of this is worth fighting. A trimmed or missing referrer cannot be restored after the fact, and a UTM tag on the link carries the source whatever the policy strips.

Frequently asked questions

Is it Referer or Referrer in an HTTP request?

The request header is Referer, the only spelling RFC 9110 defines and the one browsers send. RFC 9110 marks the name with "[sic]" and explains that the field name is misspelled. Server variables built from that header, such as PHP's HTTP_REFERER, keep the typo. Names coined later use Referrer, such as the Referrer-Policy response header.

Why was the Referer typo never fixed?

The header was already in production traffic when RFC 1945 documented it in May 1996, and every server reads it by that exact name. RFC 2068 added a "[sic]" in January 1997, and every HTTP specification since has kept the annotation instead of renaming the field.

Can I set the Referer header with fetch()?

No, because MDN lists Referer as a forbidden request header, so the browser ignores it in the headers object. Use the referrer option on the request instead. An empty string omits the header, and a same-origin URL sets it.

Does the Referrer-Policy header use the misspelling?

No. The W3C Referrer Policy specification states that "The header name does not share the HTTP Referer header's misspelling." The same applies to the referrerpolicy attribute, the referrer meta name and rel="noreferrer".

Why is document.referrer empty?

document.referrer is empty when the visit had no referring page, such as a bookmark or a typed address, and when policy or markup suppressed it. A rel="noreferrer" link, a no-referrer policy, and an HTTPS page linking to an HTTP page all produce an empty value under the default rules.

Why does PHP call it HTTP_REFERER?

PHP builds $_SERVER keys from request header names by prefixing HTTP_, uppercasing, and replacing hyphens with underscores. The header is Referer, so the key is HTTP_REFERER. Django follows the same pattern in request.META.

What is the default referrer policy in browsers?

The W3C draft sets the default to strict-origin-when-cross-origin. It sends the origin, path and query string on same-origin requests. On cross-origin requests it sends only the origin while the protocol security level stays the same, and it sends no Referer header from HTTPS to HTTP.

What is the difference between rel="noreferrer" and no-referrer?

rel="noreferrer" is a link relation and is written without a dash. no-referrer is a policy value, so the document-wide form is <meta name="referrer" content="no-referrer">, with a dash. Swapping the two silently does nothing.

Does Express accept both Referer and Referrer?

Express accepts both. The req.get docblock calls the two names interchangeable, and the code returns this.headers.referrer || this.headers.referer. A header literally named Referrer wins over the standard one.

Which RFC first defined the Referer header?

RFC 1945, the HTTP/1.0 document dated May 1996, defines it in section 10.13 and says nothing about the spelling. RFC 2068 added the [sic] in January 1997. RFC 9110 still carries it in June 2022.