b2KIT

Referrer Policy Generator

Select and configure the optimal Referrer-Policy header with comparison of all policy options and their effects.

Tested tool guide Tested browser tools Checked August 16, 2026

What Referrer Policy Generator does, with a checked example

The Referrer-Policy header tells browsers how much of the referring URL to attach to outgoing requests as the Referer header. This tool lists every policy value, from no-referrer to unsafe-url, and for each shows what gets sent on same-origin, cross-origin, and HTTPS-to-HTTP downgrade requests, then hands you the header line plus the meta-tag and attribute forms ready to paste. The thing most people get wrong: browsers already default to strict-origin-when-cross-origin, so setting a policy is almost always a deliberate tightening - and origin and strict-origin differ only in what happens when a request drops to plain HTTP.

Worked example

A concrete input and expected output from the current implementation.

Input

Select origin-when-cross-origin, then enter https://example.com/blog/post?ref=home as the page URL.

Expected output

Referrer-Policy: origin-when-cross-origin

Same-origin request (https://example.com/...): sends https://example.com/blog/post?ref=home - full URL
Cross-origin HTTPS request (https://analytics.example.net): sends https://example.com - origin only
HTTPS-to-HTTP request (http://legacy.example.net): sends https://example.com - origin still sent

origin-when-cross-origin sends the full URL only when the destination is the same origin and truncates to the origin for every different-origin destination. The HTTPS-to-HTTP case is cross-origin because the scheme is part of the origin, so the origin still goes out - only no-referrer-when-downgrade and the strict- values suppress the referrer on downgrades.

How the result is produced

1

The policy ladder

The eight values form a disclosure spectrum: no-referrer sends nothing; no-referrer-when-downgrade sends the full URL except on HTTPS-to-HTTP downgrades; origin and strict-origin send only scheme, host, and port, differing purely on downgrades; same-origin keeps full URLs inside the origin and nothing outside; the two origin-when-cross-origin variants mix full and truncated URLs; unsafe-url sends everything everywhere. The tool lays these out in a comparison table covering same-origin, cross-origin, and HTTPS-to-HTTP requests.

2

Where the policy lives

The same value can be deployed three ways with different reach: the Referrer-Policy response header, which applies to everything the page loads and to the navigations it starts; a <meta name="referrer" content="..."> tag in the head, which covers the document's subresources but is ignored for the request that fetched the document itself; and a referrerpolicy attribute on <a>, <img>, <iframe>, <link>, and <script> elements, taking precedence over the other two. The generator emits all three forms.

Good uses

  • Picking a policy for a privacy-sensitive release - your pages carry utm_* parameters or signed tokens in their URLs, and you need to know which requests would still expose them under each candidate value.
  • Tightening without breaking your own flows - a checkout page that must keep the full Referer for same-origin CSRF validation while suppressing it on third-party requests, which points to same-origin.
  • Auditing a header you inherited - the old site sends unsafe-url or no-referrer-when-downgrade, and you need a readable statement of what those expose, including full URLs over plain HTTP in the unsafe-url case, before changing anything.

Limits and checks

  • The header that carries this policy is Referrer-Policy (two r's), while the request header it controls is Referer (one r, a typo frozen into the spec). Browsers silently ignore a misspelled header - no warning, no effect - so verify the spelling in your server config and logs before assuming the policy is live.
  • Downgrade behavior is the trap in the comparison table. origin and origin-when-cross-origin keep sending the origin over plain HTTP, so an HTTP mirror of your site still learns where visitors came from; only no-referrer-when-downgrade and the two strict- values go silent on HTTPS-to-HTTP.
  • Server-side Referer checks break first. Frameworks that validate the Referer header for CSRF defense start rejecting legitimate cross-origin form posts once the policy is no-referrer, same-origin, or a strict- value, because no referrer arrives at all. Also, HTTPS-to-HTTP to the same host is cross-origin by definition - the scheme is part of the origin.

Common questions

Which policy should I actually use?

For most sites, strict-origin-when-cross-origin - also the value browsers use by default when no Referrer-Policy header is present - keeps full URLs for same-origin requests, sends only the origin to other HTTPS sites, and sends nothing on HTTPS-to-HTTP downgrades. Choose no-referrer or same-origin when nothing should ever leave your site, and unsafe-url only if you deliberately want full attribution on every request, plain HTTP included.

I added the meta tag and nothing changed. Why?

The meta tag must be in the head, and it governs only requests that document makes - its subresources and the navigations it starts. It never applies to the request that fetched that page; that request follows the policy of whatever page or link initiated it. A meta tag placed in the body is ignored entirely.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools