Referrer-Policy Inspect

Diagnose security headers and policies in your browser. No input is sent to a server. Use it for first-pass checks before rollout.

Status

Runs in your browser. No input is sent to a server. Use this as a first-pass diagnostic step.

How to use

Paste Referrer-Policy and click “Parse”. It lists policy values.

Notes (this tool)

  • Accepts Referrer-Policy: header, meta content, or raw values.

About this page

What does this tool do?

Parse Referrer-Policy and list which policy values are set.

Useful for checking ordering when multiple values are present and spotting unintended values.

Referrers impact privacy and security, making this header a frequent audit target.

Referrer-Policy basics

  • Controls how much referrer (origin or full URL) is sent.
  • “no-referrer” sends nothing.
  • “origin” sends only the origin.

Typical use cases

  • Reduce leakage when navigating to external sites
  • Keep internal referrers detailed but minimize for external
  • Review privacy settings during security audits

Common policy values

  • no-referrer: send nothing
  • strict-origin-when-cross-origin: full on same-origin, origin on cross-origin (no downgrade)
  • same-origin: only same-origin
  • origin-when-cross-origin: full on same-origin, origin on cross-origin

Syntax (how to read)

Referrer-Policy can contain multiple comma-separated values. Browsers use the last value they understand (for fallback).

  • Referrer-Policy: no-referrer, strict-origin-when-cross-origin (new browsers pick the latter)
  • You can set it via header or <meta name="referrer" content="...">.

Thinking about defaults

If you don’t set it, behavior depends on browser defaults and environment. For predictable operations, set it explicitly.

A common modern choice is strict-origin-when-cross-origin: it keeps internal analytics useful while reducing external leakage.

Privacy & leakage angle

Referrers can include paths and query strings. If your URLs contain user IDs or tokens, they may leak to external sites or logs.

  • Limit to origin (or send none) for external destinations
  • Keep tracking params like UTM, but avoid sensitive data in URLs

Analytics/marketing trade-offs

A stricter policy can make analytics less detailed. The right balance depends on your needs (internal vs external, B2B vs B2C).

  • Need internal analytics: full on same-origin, origin on cross-origin (strict-origin-when-cross-origin)
  • High sensitivity: consider no-referrer

Common pitfalls

  • Multiple values set but the order is unintended
  • Missing the downgrade behavior (HTTPS→HTTP)
  • Overlooking iframe/third-party navigation behavior

Referrer-Policy sets a global policy, but you can also control it per link.

  • Use rel="noreferrer" on a link (no referrer for that link)
  • Use <meta name="referrer" content="..."> for page-level control

What this tool does

  • Split and display policy values
  • Check order when multiple values are set
  • Spot unintended values

Suggested workflow

  • Paste current header → confirm intended values
  • Define requirements (analytics vs sensitivity) and choose a policy
  • Verify actual referrers in Network/DevTools during navigation

Operational notes

  • Recommended values are environment-dependent. Validate against functional requirements before applying.
  • In production, use phased rollout with report monitoring.

Referenced specs

  • Referrer Policy (W3C)
  • MDN: Referrer-Policy

FAQ

Why specify multiple values?

To provide fallbacks for older browsers. The last supported value is used.

How is it different from CSP referrer?

CSP referrer is deprecated; Referrer-Policy header is recommended.

How is it different from CSP / CORS / Permissions-Policy?

Referrer-Policy controls referrer info. CSP controls resource loading, CORS controls cross-origin reads, and Permissions-Policy controls access to browser features.

References

  1. Referrer Policy
  2. MDN: Referrer-Policy

These links are generated from site_map rules in recommended diagnostic order.

  1. HSTS Inspect — Parse HSTS to verify HTTPS enforcement
  2. Permissions-Policy Inspect — Parse Permissions-Policy and review feature restrictions
  3. X-Frame-Options Inspect — Parse X-Frame-Options to validate clickjacking protection
  4. CSP Report Analyzer — Analyze CSP report JSON and summarize violation patterns
  5. Security Headers Audit — Audit presence of major security headers
  6. Security Headers Recommendation — Suggest recommended values for missing headers
  7. Security Headers Fix Plan — Create a prioritized header-fix plan
  8. CSP Nonce/Hash Helper — Generate and verify CSP nonce/hash values

Security Headers

Go from missing-header detection to concrete fix planning

Example

Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: no-referrer, strict-origin-when-cross-origin