Referrer Policy Generator

When a browser asks for a page, an image or a script, it usually says where it was standing when it asked. The request carries a header named Referer, and its value is an address: the page that held the link or loaded the resource. Most people never see it. Every server on the receiving end does.

The name is a spelling mistake. The header was proposed with one r missing, and by the time HTTP/1.0 was written down in May 1996 the error was fixed in place. The current HTTP specification still marks the field name with a dry “sic”. When the policy header arrived two decades later its authors spelled it properly, so a site today sets Referrer-Policy in order to govern Referer, and anyone who types the second spelling into the first gets a header that browsers ignore.

What the header gives away

The original purpose was housekeeping. HTTP/1.0 describes the field as a way for a server to build lists of back-links, to log, and to trace mistyped or obsolete links for maintenance. Those uses survive. Analytics that say which site sent a visitor rest on it, and so do some payment and sign-in flows that check where a request came from.

The trouble is that an address is rarely just a location. It can name an account, a search, a document, a stage in a form. HTTP itself warns that the field can reveal a user’s browsing history, or a resource that was meant to stay inside a firewall. The specification for referrer policies opens with two plain cases: a social profile page whose address identifies its owner, and a web application that keeps a session identifier in the address and links to other sites.

Query strings are where it goes wrong most visibly. In January 2015 researchers at a digital rights group reported that the United States federal health insurance marketplace was passing personal details to at least 14 third-party domains. Nobody had decided to hand them over. The page that listed a visitor’s eligible plans had an address containing their age, zip code, income, and whether they smoked or were pregnant, and the page loaded resources from other companies. Each of those requests carried the address along.

The same mechanism threatens any address that works as a key. A password reset link, a private share link or an unlisted document is a capability: whoever holds the address holds the access. A W3C draft on such addresses notes that following a link from a page reached that way can hand the capability to the linked site through the Referer header. Guidance for developers makes the matching point about embedded content: an image from another site on a reset page is enough.

Two parts of an address never travel. HTTP forbids the fragment, the piece after the hash sign, and any user name and password written before the host. The policy specification strips the same three things before it does anything else.

Eight ways to trim an address

A referrer policy is one of eight keywords. Each answers the same question with one of three results: send the full address (fragment and login removed), send only the origin, or send no header at all. The origin is the scheme, host and port, written with a closing slash, so a page deep inside a shop becomes simply the shop’s front door.

Two tests decide between the results. The first is whether the page and the destination share an origin, which means the same scheme, the same host and the same port. A default port that is written out counts as the default, so port 443 on an https address changes nothing. A different subdomain does: it is a different host and therefore a different origin, however closely related the two sites are in the owner’s mind.

The second test is the downgrade. The specification asks whether each address is “potentially trustworthy”, a term borrowed from the Secure Contexts specification. Addresses using https or wss qualify. So do the loopback addresses, and names such as localhost in a browser that never sends those names out to the network. A request is a downgrade when the page is trustworthy and the destination is not, the ordinary case being an https page linking to plain http.

With those tests the eight values fall into place. no-referrer sends nothing, ever. unsafe-url sends the full address, always, and the specification remarks that the name does not lie. origin sends the origin to everyone. same-origin sends the full address to the page’s own origin and nothing elsewhere. origin-when-cross-origin sends the full address at home and the origin abroad. The other three add the downgrade rule. no-referrer-when-downgrade sends the full address unless the request is a downgrade, in which case it sends nothing. strict-origin sends the origin, and nothing on a downgrade. strict-origin-when-cross-origin combines everything: the full address at home, the origin to other trustworthy origins, nothing on a downgrade.

Take a reset page at https://app.example.org/account/reset?token=8f3a1c9e&user=42#step-2 that loads a script from https://cdn.example.net/lib.js. The origins differ because the hosts differ, and both are https, so nothing is downgraded. Under unsafe-url or no-referrer-when-downgrade the script’s server receives https://app.example.org/account/reset?token=8f3a1c9e&user=42, token included. Under origin, strict-origin, origin-when-cross-origin or strict-origin-when-cross-origin it receives https://app.example.org/. Under no-referrer or same-origin it receives nothing. The tool on this page shows the same eight answers for that pair when it opens.

One more trim is automatic. If the stripped address is longer than 4096 characters, the current draft has the browser fall back to the origin, whatever the policy says.

Why the default moved

A page that sets no policy gets the browser’s default. The edition of the specification published on 26 January 2017 named no-referrer-when-downgrade for that role: full addresses to anyone, as long as the connection stayed encrypted. It protected against eavesdroppers on the wire and did nothing about the companies at the other end of it.

The default then changed. Developer documentation records the specification’s revision in November 2020, and a table of the major browsers compiled in October 2021 shows each of them using strict-origin-when-cross-origin or something close to it. The editor’s draft dated 20 March 2026 states it without qualification. Other sites now learn which site sent a visitor, and no longer which page, unless the sending site asks otherwise.

The practical effect is that the reset page above is safer than it was, with no effort from its author. It is also a reason to set a policy on purpose. A site that relies on the default behaves differently in an old browser than in a new one, and the people who run it may never notice until a partner complains that addresses have gone missing.

Choosing for a site and for a link

No single value suits every site, and the specification says as much: it is not clear which policy is stricter for every possible pair. origin reveals less than no-referrer-when-downgrade to other sites, yet it sends that origin over an unencrypted connection, which the other never does. The choice trades what strangers learn against what your own tools receive.

A reasonable way to think about it starts from the default and asks what it breaks or leaks. An intranet tool whose host names are themselves confidential may want same-origin or no-referrer. A publisher whose partners attribute traffic by page may accept no-referrer-when-downgrade, knowingly. A shop whose payment provider checks the incoming origin needs at least the origin to reach that provider.

Policies also come in sizes. The response header covers a whole document. A meta element named referrer does the same from inside the page and takes precedence over the header. A referrerpolicy attribute on a link, image, script or frame overrides both for that one element, and rel="noreferrer" on a link beats everything and sends nothing. A strict site-wide value with one looser link to the payment provider is usually better than loosening the whole site.

The header accepts a comma-separated list, and the last value a browser understands wins. That lets a site name an older value first and a newer one after it. The meta element and the attribute take a single value only.

A policy has limits worth stating. It governs one header and the matching script property, nothing more. A script from another company running in the page can read the address directly. Browsers are free to send less than the policy allows, and some trim further for privacy. The header is also the wrong tool for defending against forged cross-site requests, where tokens do the job. Bookmarks, browser history and server logs keep addresses too, and no header setting reaches them. The surest protection for a secret is still to keep it out of the address.