Test and configure Referrer-Policy headers. Visualize which referrer information is sent for different policy values.
Every request a browser makes can carry a Referer header (the HTTP spelling, one r) naming the page you came from, and how much of that URL is revealed is controlled by a policy you set. This tool lets you pick a policy value, a source page, and a target, then shows the exact header a browser would attach. Two facts surprise almost everyone: the target site has no say over what it receives, and setting no policy does not mean full URLs are sent - modern browsers default to strict-origin-when-cross-origin, which sends only your origin on cross-origin HTTPS requests and nothing on downgrades to HTTP.
A concrete input and expected output from the current implementation.
Input
policy: strict-origin-when-cross-origin source: https://example.com/products/widget.html target: https://analytics.example.net/collect
Expected output
Referer: https://example.com
Source and target are cross-origin, so the strict default strips everything down to scheme, host, and port - the product path stays private. The same request to a same-origin page would carry the full URL, and a target on plain http:// would receive no header at all.
For each policy value the tool computes what the Referer field will contain from three inputs: the policy, whether source and target share an origin, and whether the request downgrades from HTTPS to HTTP. Every outcome is one of three forms - no header, the bare origin (scheme, host, port), or the full URL with path and query. Fragments and credentials are stripped in every case, including unsafe-url.
A policy can be set at four layers with descending precedence: a referrerpolicy attribute on one element, a meta name="referrer" tag, the Referrer-Policy HTTP header, and the browser default, strict-origin-when-cross-origin. The tool shows the equivalent header line and HTML snippets for the policy you choose, because the layers do not cover the same requests - a meta tag does not govern the page's own initial request or its redirects.
For the header alone, yes - it sends nothing at all. But it also breaks referrer-based analytics and hides the path from your own same-origin requests, which some apps need. Most sites prefer strict-origin-when-cross-origin, which keeps the full URL inside your origin and shows only the bare origin to cross-origin HTTPS hosts. And the header is one channel only: referrers still leak through URL parameters and navigation history.
No. Your header governs only the requests your own pages initiate. When a visitor clicks a link on another site to reach you, the referrer they send is controlled by that linking site's policy and the request context, not by yours. You cannot block inbound referrers from your server; that requires either every linking site to cooperate or a browser-level privacy setting.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.