Build a correct Referrer-Policy header, compare browser privacy tradeoffs, and preview what referrer data gets sent on same-origin, cross-origin, HTTPS, and downgrade requests.
Pick a preset or inspect how each policy behaves before copying the final header or meta tag.
Use custom URLs to preview the exact referrer value that a browser would send under the selected policy.
Header, HTML meta tag, and common server snippets are generated from the selected policy.
A quick read on what your selection means operationally.
Copy ready-to-use examples for deployment.
Practical defaults for app teams, marketing sites, and strict privacy contexts.
strict-origin-when-cross-origin for most apps. It keeps full referrers on same-origin requests, sends only origins cross-site, and strips data on HTTPS → HTTP downgrades.same-origin if you never want third parties to receive referrer details but still want internal analytics and routing context.strict-origin when you still want cross-site origin-level attribution without leaking paths or query parameters anywhere.no-referrer for highly sensitive products, internal tools, auth flows, or regulated environments where privacy beats attribution.unsafe-url unless you explicitly accept leaking full URLs, including path and query data, to other origins over HTTPS.