HTTP · HEADERS · SECURITY ANALYSIS

HTTP Headers Checker

Retrieve the HTTP response headers returned by any URL. Examine security headers, server software, caching directives, and redirect chains.

~/pingie - http-headers
ready

Type in a URL to examine the HTTP response headers it returns.

The toolkit

Every network tool you'll ever need.

Purpose-built utilities for ports, IPs, DNS and email. Completely free, all powered by external probes.

HTTP headers checker: What it does and why it matters

When a browser requests a web page, the server responds with a set of HTTP response headers before any HTML is delivered. These headers carry instructions that control caching, content type, security policies, and more. Many of those instructions are optional, and sites that omit the important ones leave browsers without guidance on how to handle potential threats.

The HTTP headers checker on Pingie retrieves all response headers from a URL and runs a security analysis against them. It scores the configuration from 0 to 100 and flags headers that are missing, present, or misconfigured.

What the security score measures

The score reflects how well a site's headers align with established browser security directives. Each header contributes a fixed number of points, and the total gives you a clear picture of where the configuration stands.

  • Content-Security-Policy (CSP) : 20 points. Controls which resources the browser may load, reducing the risk of cross-site scripting attacks.
  • Strict-Transport-Security (HSTS) : 15 points. Instructs browsers to use HTTPS for all future requests to the domain, even if the user types HTTP.
  • X-Frame-Options : 10 points. Prevents the page from being embedded in iframes, blocking clickjacking attempts.
  • X-Content-Type-Options : 10 points. When set to nosniff , stops browsers from guessing a file's MIME type and executing it as something else.
  • Referrer-Policy : 5 points. Determines how much referrer information is included when a user follows a link away from the page.
  • Permissions-Policy : 5 points. Restricts which browser features, such as camera, microphone, or geolocation, the page is allowed to access.
  • No Server header exposed : 5 points. Hiding the Server header prevents revealing software versions that attackers can use to target known vulnerabilities.
  • No X-Powered-By header exposed : 5 points. Same principle as above, applied to the framework or runtime powering the application.

A perfect score of 100 is a useful benchmark, not a guarantee of full security. Equally, a low score does not confirm that a site is actively vulnerable. The score is a structured starting point for review.

How to check site headers with this tool

The process is straightforward and requires no account or configuration.

  1. Navigate to the HTTP Headers Checker from the tool menu.
  2. Enter the full URL you want to inspect, including the protocol ( https:// ).
  3. Click Check . The tool sends a request to the target URL and captures the raw response headers.
  4. Review the complete list of headers returned by the server.
  5. Read the security score and the breakdown showing which headers are present, which are missing, and which are misconfigured.
  6. Act on the warnings and recommendations listed below the score to address gaps in the configuration.

If the target server has a TLS certificate issue, the tool retries the request without certificate verification so you still get the header data. This is useful when you need to check a staging environment or an internal server with a self-signed certificate.

When to use a security header checker

Checking response headers is relevant at several points in a site's lifecycle, not just during initial setup.

  • After deploying a new server configuration or CDN, to confirm headers are being sent as intended.
  • During a security audit, to document the current header posture before making changes.
  • When reviewing a third-party site, to assess its header hygiene before integrating or linking to it.
  • After a framework or platform upgrade, since updates sometimes reset or remove custom header rules.
  • When troubleshooting mixed-content warnings or CSP violations in the browser console.

A note on CSP and information disclosure headers

Content-Security-Policy carries the highest point value in the scoring breakdown because it is also the most complex to configure correctly. A generic CSP recommendation cannot account for the specific scripts, styles, and resources each site loads. The tool flags its absence and suggests adding one, but the actual policy must be written to match the site's real resource requirements.

The Server and X-Powered-By headers are flagged for a different reason. They do not directly harm users, but they advertise the software stack to anyone who inspects the response. Attackers use that information to look up known exploits for specific versions. Removing or obscuring these headers is a low-effort step that reduces information exposure.

For a fuller picture of a domain's configuration, you can also run a DNS lookup or check email authentication records with the DMARC checker .

FAQ

An HTTP headers checker sends a GET request to a URL and captures the response headers the server returns. It then displays those headers in a readable format and, in the case of this tool, evaluates them against a set of security directives. The result tells you which security-relevant headers are present, which are missing, and what the overall configuration score is out of 100.

The tool assigns a fixed number of points to each security-relevant header. Content-Security-Policy is worth 20 points, HSTS is worth 15, X-Frame-Options and X-Content-Type-Options are worth 10 each, and Referrer-Policy and Permissions-Policy are worth 5 each. Hiding the Server and X-Powered-By headers adds 5 points each. Points are deducted when those headers are absent or when information-disclosure headers are present. The total out of 100 reflects the overall posture.

No. The score measures header configuration only. A site can have all the right headers in place and still have vulnerabilities in its application code, database layer, or server configuration. The score is a useful indicator of header hygiene, not a comprehensive security audit. Treat it as one input among several, not as a final verdict on the site's overall security posture.

You can check any publicly reachable URL. If the server uses a self-signed or otherwise invalid TLS certificate, the tool automatically retries the request without certificate verification so you still receive the header data. Internal servers that are not accessible from the public internet cannot be reached, since the request originates from Pingie's servers, not your local machine.

These headers often include the name and version of the web server software or application framework. That information is useful to attackers because they can cross-reference it against public vulnerability databases to find known exploits for that specific version. Removing or obscuring these headers does not fix underlying vulnerabilities, but it removes a free source of reconnaissance data. The tool deducts points when either header is present and reveals technology details.

This tool inspects HTTP response headers, which are delivered by a web server when a browser or client requests a page. It focuses on browser-level security directives. A DMARC checker queries DNS records to evaluate email authentication policy. One operates at the HTTP layer for web traffic; the other operates at the DNS layer for email. They address different attack surfaces and are complementary rather than overlapping.

CSP is weighted at 20 points because it provides the broadest protection of any single header. It instructs the browser on which origins are allowed to serve scripts, styles, images, fonts, and other resources. A well-configured CSP significantly reduces the impact of cross-site scripting attacks by preventing the browser from executing injected code. However, it is also the hardest header to configure correctly, since the policy must match each site's specific resource requirements precisely.

HSTS (Strict-Transport-Security) tells the browser to use HTTPS for all future requests to the domain, for a specified duration. Once the browser receives this header, it will not make plain HTTP requests to that domain during the policy period, even if the user types http:// manually. This prevents protocol downgrade attacks where an attacker intercepts an initial HTTP request before a redirect to HTTPS can occur.

The tool processes the URL and returns results for your session. No personally identifiable information is required to use it. For full details on how Pingie handles data, refer to the privacy policy . Avoid submitting URLs that contain sensitive tokens or credentials in the query string, since those would be transmitted as part of the request.

X-Frame-Options tells the browser whether the page is allowed to be rendered inside an iframe on another domain. When set to DENY or SAMEORIGIN , it prevents attackers from embedding the page in a transparent overlay on a malicious site, a technique called clickjacking. The attacker's goal is to trick users into clicking elements they cannot see, such as confirmation buttons or permission grants. This header is a direct countermeasure to that technique.

Browser developer tools show you the headers for your own browsing session and require you to manually identify which security headers are missing. This tool retrieves headers from the server's perspective, scores them automatically, and lists specific warnings and recommendations. It is faster for auditing purposes and provides a structured output rather than a raw list. It is also useful for checking URLs you do not want to visit directly in a browser.

Permissions-Policy (formerly Feature-Policy) allows a site to declare which browser features it needs and explicitly block access to others. For example, a site that has no need for camera or geolocation access can use this header to prevent any script on the page from requesting those permissions. This limits the blast radius if a third-party script loaded by the page is compromised or behaves unexpectedly. The tool flags its absence as a missed opportunity to restrict feature access.