What HTTP response headers tell you
Every page load starts with a set of headers the server sends before any content - they reveal the server software, caching rules, security policies (like HSTS or Content-Security-Policy), cookies being set, and redirect targets. Checking them directly is useful for debugging a caching issue, confirming a security header actually went live after a deploy, or seeing exactly what a server returns without opening developer tools.
Why checking headers directly matters more than reading a page's visible content
Headers carry information a page's visible content never shows - a cache-control policy, a security header, or a cookie being set all happen before a single pixel of the page renders, which is why diagnosing a caching or security-configuration issue usually means looking at exactly what this tool shows rather than what appears on screen.
Why this tool deliberately does not follow redirects
Showing the headers for exactly the URL entered - including a redirect's status code and Location header, without silently following it to a final destination - gives a clear, unambiguous picture of what that one specific URL actually returns, which matters when diagnosing a redirect itself rather than the page it points to.
Why private or internal network addresses aren't allowed
Allowing a public tool to fetch internal or private network addresses on a user's behalf opens the door to exactly the kind of network-probing abuse that server-side request tools are commonly restricted against - this tool sticks to fetching public, internet-facing URLs only.