DNS Tools
PRIVACY HEADERS

Referrer Policy Checker

Check how much of a page's address is revealed to other websites when visitors follow links or load resources, according to the Referrer-Policy header.

Run Referrer policy

The domain (or a subdomain). The check stays within that name and its www counterpart, like the full assessment.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What the referrer is

When a browser requests a resource or follows a link from one page to another, it can send a Referer header telling the destination which URL the visitor came from. That is useful for analytics, but it can leak sensitive details when addresses include account identifiers, search terms, tokens or internal paths. The Referrer-Policy response header lets a site choose how much to reveal: the full URL, only the origin, or nothing.

The policy values

The tool parses the header and shows the effective policy. When several comma-separated tokens appear, browsers use the last one they recognise, which allows fallbacks for older browsers.

  • no-referrer: nothing is sent.
  • same-origin: the full URL goes to your own site only; nothing to others.
  • strict-origin: only the origin, and nothing on a downgrade from HTTPS to HTTP.
  • strict-origin-when-cross-origin: full URL within your site, the origin to other sites, nothing on downgrade. This is the default in modern browsers when no policy is set.
  • origin and origin-when-cross-origin: send the origin even on downgrade, less protective than the strict variants.
  • no-referrer-when-downgrade and unsafe-url: flagged as permissive. unsafe-url sends the full URL, including path and query, to everyone, even over insecure connections.

How to read the verdict

A missing header is informational, because modern browsers already apply strict-origin-when-cross-origin; older browsers may apply a more permissive default. A permissive policy whose entire value is unsafe-url or no-referrer-when-downgrade is flagged as a low-severity improvement. Anything else passes. The tool also notes invalid tokens, which browsers ignore, and warns when the effective policy is permissive even if the header as a whole did not trigger the check.

Referrers and privacy rules

Referrer data can contain personal information when addresses carry names, email addresses or search terms. Even when you do not intend to share it, a permissive policy sends it to every site you link to and every third-party resource you load, such as fonts, images and advertising scripts. Treating the policy as part of your privacy design, alongside not putting personal data in URLs, keeps the behaviour predictable. This tool reports what your header does; it does not interpret legal obligations.

Common problems

  • unsafe-url set deliberately for analytics and later forgotten, leaking paths and query strings.
  • Typos such as strict-origin-when-crossorigin, which browsers ignore, leaving the default.
  • Sensitive URLs: reset links or session identifiers in the URL, which should not exist regardless of policy.
  • A policy that breaks a partner's analytics or payment return check that expects the full referrer.
  • Per-link settings (rel=noreferrer or a referrerpolicy attribute) overriding the header, which this tool cannot see.

How to set a referrer policy safely

Prerequisites: know which third parties rely on the Referer from your pages, for example affiliate programs, payment return flows and analytics. Risk: reducing the referrer can change attribution numbers or break a check that reads it. Rollback: restore the previous header. The change takes effect on the next page load.

  1. Check whether any partner or internal system needs full URLs from your pages.
  2. Set Referrer-Policy: strict-origin-when-cross-origin as a balanced default, or no-referrer for sensitive applications.
  3. Remove tokens, identifiers and secrets from URLs, because policies do not secure what is already in an address.
  4. Re-run this checker and review analytics for changes in referral reporting.

Limits

Policies set with a meta tag, a rel=noreferrer link or an element attribute are not seen. Only the landing response is examined. A tool cannot tell which URLs on your site are sensitive. The header controls what a browser sends, not what other parties do with it.

Frequently asked questions

Do I need to set Referrer-Policy if browsers have a default?

It is not required, but setting it explicitly makes behaviour consistent across browsers and documents your intent.

Which value should I choose?

strict-origin-when-cross-origin is a common balanced choice. Use no-referrer where no one needs the information.

Why is unsafe-url flagged?

It sends the full URL, including path and query, to every destination, even over insecure connections.

Will changing it break analytics?

It can change what referral data other sites receive. Review your reports after the change.

What if I list several values?

Browsers use the last one they recognise, so put the preferred value last.

Does this hide my site from being linked?

No. It only limits what is sent when visitors leave.

Scope of this tool

  • Only the domain's apex and www host are contacted over HTTPS (and port 80 where stated); redirects to any other host are reported, never followed.
  • Spectra identifies itself honestly and does not imitate a browser, so sites that block automated clients may not show their real headers.
  • A single request path (/) is examined from this scanner's network position; other pages, other nodes of a load-balanced site and other regions may differ.
  • If a header is sent more than once, only the first occurrence is examined.
  • Error and redirect responses are not judged: their headers are not representative of the site.

Written by DNS Tools editorial · Last updated 2026-10-09