HTTP Headers Checker

What HTTP response headers reveal

HTTP headers are metadata exchanged between a client and a web server. They describe how a request should be handled, how a response should be cached, what content is being returned, whether a redirect is taking place, and which browser security controls may apply. The page body is usually what visitors see, but headers often explain important behavior that is not visible in the rendered page.

The HTTP Headers Checker lets you inspect a URL’s HTTP response in a readable form. It reports the HTTP status code, response headers, server-related hints, and notable security headers. This can help you understand how a site responds before investigating deeper issues involving DNS, TLS, caching, redirects, or application configuration.

A response normally contains a status code such as 200 OK, 301 Moved Permanently, 404 Not Found, or 500 Internal Server Error. It may also include headers such as Content-Type, Location, Cache-Control, Set-Cookie, Strict-Transport-Security, and Content-Security-Policy. Each one provides a clue about the server’s behavior, although no single header gives a complete security or performance assessment.

How the HTTP Headers Checker works

The tool requests the URL you provide and examines the HTTP response returned by the destination. It reads the status code and the response header fields, then presents them for inspection. If the URL responds with a redirect, the result may show redirect-related information such as the Location header. Review the reported request and response context carefully, particularly when testing a URL that redirects between HTTP and HTTPS or between several hostnames.

Headers are generated by different layers. A web server may add basic response fields, a reverse proxy may add forwarding or caching information, a content delivery network may modify or append headers, and the application may add cookies or security policies. As a result, a header can indicate the behavior of one layer without describing every component behind the site.

The checker observes the response available to its request at the time of testing. It does not automatically prove what happens for every browser, geographic location, user-agent, authentication state, HTTP method, or URL path. A home page and an API endpoint can return very different headers. For meaningful comparisons, test the exact URLs and conditions that matter to your investigation.

Understanding the main parts of a result

Status code

The status code is the first place to look. It indicates the broad outcome of the request:

• 2xx success: The server processed the request successfully. 200 commonly means that content was returned, while 204 indicates success without a response body.
• 3xx redirection: The client is being directed elsewhere. 301 and 308 are generally used for permanent redirects, while 302, 303, and 307 are commonly used for temporary or method-sensitive redirects.
• 4xx client or request problem: The server could not or would not fulfil the request as made. Examples include 401 Unauthorized, 403 Forbidden, and 404 Not Found.
• 5xx server-side problem: The server or an upstream service encountered an error. Examples include 502 Bad Gateway, 503 Service Unavailable, and 504 Gateway Timeout.

A status code should be interpreted with the URL and application context. A 403 may be intentional access control rather than a broken site. A 404 can be a valid response for an unknown path. Conversely, a 200 response does not guarantee that the expected content was delivered; some applications return a custom error page with a successful status code.

Common general-purpose headers

Content-Type identifies the media type of the response, such as HTML, JSON, an image, or plain text. A correct value helps clients interpret the content safely and consistently. Content-Length may indicate the response size, although it may be absent when transfer encoding or streaming is used.

Location identifies the destination of a redirect and is especially useful when checking HTTP-to-HTTPS behavior, canonical hostnames, trailing-slash rules, or legacy URLs. A redirect chain should be reviewed as a sequence rather than judged from only the first response.

Date records when a response was generated or served, while Age may indicate that an intermediary cache has stored the response. Via, Server-Timing, and related fields can provide operational hints, but their presence and meaning vary by deployment.

Cache-Control, Expires, and ETag help describe caching behavior. For example, max-age specifies a freshness period, no-store requests that a response not be stored, and ETag supports conditional requests. Caching decisions can also depend on Vary, which tells caches that a response may change according to request headers such as Accept-Encoding or Accept-Language.

Cookies and session-related headers

Set-Cookie instructs a browser to store a cookie. When reviewing it, pay attention to attributes such as Secure, HttpOnly, SameSite, Domain, and Path. The Secure attribute limits transmission to HTTPS, HttpOnly reduces access from client-side scripts, and SameSite controls when a browser sends a cookie in cross-site contexts.

A missing attribute is not automatically a vulnerability. Some cookies are not sensitive, and an application may intentionally use a particular cross-site policy. However, authentication or session cookies deserve closer review because incorrect scope or transport settings can increase exposure. Avoid copying live cookie values into tickets, screenshots, or public reports.

Security headers and how to interpret them

Security headers communicate browser policies. They can reduce certain classes of client-side risk, but they are not a replacement for secure application code, correct server configuration, access controls, or ongoing testing.

• Strict-Transport-Security: Also called HSTS, this tells supporting browsers to use HTTPS for a specified period. Review the max-age value and, where present, directives such as includeSubDomains and preload. Enabling broad coverage without confirming that every included host supports HTTPS can create access problems.
• Content-Security-Policy: CSP limits the sources and actions that browsers may accept for scripts, styles, frames, images, and other content. A policy can be highly protective or overly permissive depending on its directives. Look for broad values such as * or unsafe script allowances, but do not evaluate a policy from one directive alone.
• X-Content-Type-Options: The value nosniff asks browsers not to guess a different content type. It is most useful when the server supplies correct Content-Type values.
• Referrer-Policy: This controls how much referrer information a browser sends when navigating to another origin. Policies such as strict-origin-when-cross-origin can limit path and query-string disclosure across sites.
• Permissions-Policy: This can restrict browser features, such as camera, microphone, geolocation, or fullscreen, for a document and selected origins. The correct policy depends on what the application needs.
• Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, and Cross-Origin-Embedder-Policy: These headers influence document isolation and cross-origin resource behavior. They can be useful but may break integrations if introduced without testing dependent resources.
• X-Frame-Options: Values such as DENY or SAMEORIGIN can limit framing by other pages. CSP’s frame-ancestors is the more flexible modern control, but compatibility and application requirements should be considered.

Header presence alone is not enough. A CSP may be present but ineffective for the application’s actual resources. HSTS may appear only on HTTPS responses and may not be active for the first HTTP connection. Security headers can also differ between the main document, static assets, API responses, and error pages.

Practical use cases

Checking redirects and canonical URLs

Use the tool when moving a site to HTTPS, changing a domain, or standardizing a preferred hostname. Test the HTTP and HTTPS versions, with and without the www prefix where relevant. Confirm that redirects lead to the intended destination and do not create unnecessary loops or long chains.

Investigating browser or integration problems

When an API call, embedded resource, or third-party integration fails, inspect the response status and relevant headers. A 401 or 403 suggests an authorization or policy issue, while a restrictive CSP, CORS-related response behavior, or incorrect content type may explain browser errors. The headers checker is an initial diagnostic; browser developer tools and application logs are often needed to identify the exact failing request.

Reviewing cache behavior

Use the result to compare caching directives on public pages, private account areas, and static assets. A sensitive response should not be casually cacheable. Conversely, a public asset with unnecessarily restrictive directives may be served less efficiently than intended. Check Cache-Control, ETag, Age, and Vary together rather than focusing on one field.

Performing a basic security configuration review

Review the security headers on key pages after a server, proxy, framework, or CDN change. Record the URL, status code, and relevant header values so that you can compare behavior over time. If you need to investigate the certificate and encryption setup as well, use the related SSL Checker. For name resolution or hosting-path questions, compare the response with results from the DNS Lookup tool.

Investigating infrastructure changes

Changes to a reverse proxy or hosting provider can alter the Server, Via, caching, redirect, and error-response headers. These fields may help identify which layer is responding, but they should be treated as clues rather than definitive infrastructure disclosure. For domain registration and ownership context, use the WHOIS Lookup tool alongside HTTP testing.

Common mistakes

• Assuming a status code proves application health: A successful response can contain an application error page, while a deliberate 403 can be normal.
• Treating server banners as a full technology inventory: The Server or X-Powered-By value may be hidden, changed, incomplete, or misleading. It is not proof of the complete software stack or version.
• Judging security from header count: More headers do not automatically mean stronger security. A misconfigured policy can cause outages or provide little protection.
• Testing only the home page: Login pages, APIs, downloads, error pages, and static assets may have different policies and caching behavior.
• Ignoring redirects: Inspect each relevant hop. A final HTTPS response does not erase a problem in the initial HTTP or alternate-host response.
• Copying secrets into reports: Cookies, authorization data, signed URLs, and personal information should be redacted before sharing results.

Troubleshooting unexpected results

If the tool returns an error or a response different from your browser, first confirm that the URL is complete and uses the intended scheme. Check for spelling errors, an incorrect path, a missing port, or a hostname that is not publicly reachable. If DNS was recently changed, compare the domain’s records using DNS Lookup; different resolvers or caches may temporarily produce different destinations.

Some sites apply access controls based on IP address, geography, rate, cookies, authentication, or user-agent. A browser session may therefore receive a different response from an unauthenticated external request. WAFs and CDNs may also return their own block or challenge page. Compare the status, headers, and body context without attempting to bypass an access control.

For TLS-related failures, verify the certificate, hostname, protocol, and expiration details with the SSL Checker. A site can have valid DNS and an apparently correct HTTP configuration while still failing HTTPS negotiation. For intermittent errors, test more than once and compare timestamps, redirect destinations, and cache-related headers.

Limitations, accuracy, and responsible use

The result is a snapshot of one request, not a complete audit. Responses may vary by time, location, protocol, HTTP method, authentication state, request headers, cookies, load-balancing route, and backend health. Intermediaries can add, remove, or rewrite headers. Some security controls are enforced by browsers or infrastructure in ways that cannot be inferred from a single response.

Headers can also be syntactically present but operationally ineffective. For example, a policy may reference resources that are not covered as intended, or a cache may follow additional rules outside the visible response. Treat the checker as a practical observation and troubleshooting aid. Confirm important findings with server configuration, browser developer tools, application logs, controlled tests, and the documentation for the relevant platform.

Only inspect domains and endpoints that you own or are authorized to evaluate. Avoid sending credentials or sensitive query parameters unless the testing context explicitly permits it. HTTP response headers are normally intended for clients, but they can still expose implementation hints, cookie metadata, internal naming, or operational details. Share results carefully, redact sensitive values, and use HTTPS when entering or transmitting any information that could identify a private system.

When to use related WHOISDR tools

Use the HTTP Headers Checker for the web response itself: status codes, redirects, caching directives, server hints, cookies, and browser-facing security policies. Move to related tools when the question concerns a different layer:

• Use DNS Lookup to inspect records such as A, AAAA, CNAME, MX, and NS when a hostname resolves unexpectedly.
• Use SSL Checker to examine certificate and HTTPS configuration details that response headers cannot establish.
• Use WHOIS Lookup for registration and domain record context rather than relying on HTTP server hints.

Combining these observations creates a clearer troubleshooting path: confirm that the domain resolves to the expected service, verify that HTTPS is configured for the intended hostname, then inspect how the web server responds to the exact URL. This layered approach helps distinguish DNS problems from TLS failures, redirect errors, application responses, and header configuration issues.