Looking to control the referrer-policy of your site? There are certain privacy and security benefits. However, not all the options are supported by all the browsers, so review your requirements before the implementation.

Referrer-Policy supports the following syntax.

no-referrerReferrer information will not be sent with the request.
no-referrer-when-downgradeThe default setting where referrer is sent to the same protocol as HTTP to HTTP, HTTPS to HTTPS.
unsafe-urlfull URL will be sent with the request.
same-originReferrer will be sent only for same origin site.
strict-originsend only when a protocol is HTTPS
strict-origin-when-cross-originthe full URL will be sent over a strict protocol like HTTPS
originsend the origin URL in all the requests
origin-when-cross-originsend FULL URL on the same origin. However, send only origin URL in other cases.


You can add the following if you want to set no-referrer.

Header set Referrer-Policy "no-referrer"

And after the restart, you should have in the response headers.


Let’s say you need to implement the same origin, so you got to add the following.

add_header Referrer-Policy same-origin;

Once configured, you should have the results below.

Referrer-Policy HTTP Header

Referer is a request header that is confusing on multiple levels. First of all ‘referer’ is misspelt. (The correct spelling is ‘referrer’.) Even though this is an amusing fun fact, it also shows just how hard it is to even correct a simple mistake such as a missing ‘r’ in an HTTP header field. Just imagine how much harder it would be to correct a critical security vulnerability in a widespread protocol!

But the misspelling is not the only reason why this header is often not properly understood. Let’s take a look at how this header works.

How the Referrer-Policy Header Works

You are the owner of website A and you want your visitors to check out website B. You do this by placing a hyperlink to Website B on your homepage. If users click on the link, their browser will automatically add the Referer header to the request headers. It’s content will be the address of website A. This has the advantage that Website B can see who linked to their site just by checking the Referer header of each incoming request. The Referer header will be added to requests made for style, image, script loads, and form submissions. The request would look like this:

GET / HTTP/1.1

You might want to hide the information in the Referer header for multiple reasons, such as security and privacy.

As a response header, Referrer-Policy gives you the following options to help control the Referer request header. Note how Referrer-Policy is written with a double r (rr). Arguably, this just adds to the Referer/Referrer spelling confusion even though it’s the correct way to write it.

The Referrer-Policy header can be set up in HTTP response messages as follows:

Referrer-Policy: no-referrer

Referrer-Policy Directives

Here are all potential values the Referrer-Policy header can send.



” ” (empty):

This indicates that the Referrer-Policy is not set and that the directive to control referer can be set by an HTML element on the page. This can be done by utilizing

tags or specifying a policy for individual HTML tags using the rel or referrerpolicy attributes.



This will not add any Referer header even if the redirected page has the same origin as the host.

Referrer-Policy: no-referrer


In case of a protocol downgrading (passing from a more secure protocol to a less secure one, such as HTTPS to HTTP), the Referer header will not be sent.

Referrer-Policy: no-referrer-when-downgrade

This is the default behavior of all browsers.


This only sends the Referer header if the target site is of the same origin (scheme, domain, and port must match). You can read more about this in Introducing the Same-origin Policy Whitepaper.

Referrer-Policy: same-origin


This truncates the path portion of the URL in the Referer header. As mentioned above, the origin consists of the scheme, domain, and port.

Referrer-Policy: origin

During protocol-downgrading (switching from HTTPS to HTTP), path information will be omitted and only origin data will be sent to the HTTP website within the referer.


This value will ensure that the browser only sends the origin as the referrer when the protocol security level stays the same (e.g. HTTPS and HTTPS), but that it won’t send it to a website with a lower security level, such as from HTTPS to HTTP.

Referrer-Policy: strict-origin


If the target and host websites have the same origin, the Referer header will include the full url. If the two have different origins, only scheme and domain data will be included in the Referer header.

Referrer-Policy: origin-when-cross-origin

Origin data will also be sent to the requested HTTP site with the Referer header in case of protocol downgrading.


Using this option, the origin in the Referer data will only be visible when the target and host website share in the same protocol security level or the target site is of a higher one.

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


Browsers will share the full URL in the Referer header in every request done from the host to the target website.

Referrer-Policy: unsafe-url

You should note that with this option, the full URL will be shared even from secure to unsafe connections. This option opts you out of the default behavior of browsers (avoiding URL visibility in protocol downgrading) and therefore should be used with caution.

Which Browsers Support Referrer-Policy Security Header?

Yet again, this header is not supported equally well in all modern browsers. In the image below you can see which browsers fully support Referrer-Policy and which don’t. For further information, visit the link below the image.


Check Your Security Headers

HTTP security headers are a fundamental part of website security

‘HTTP Security Response Headers’ allow a server to push additional security information to web browsers and govern how the web browsers and visitors are able to interact with your web application.

Scroll to Top