HTTP Headers Checker

About this tool

HTTP Headers Checker on UtilityKit shows the status code and response headers for any public http or https URL — no DevTools, curl or Postman needed. Browsers cannot read most response headers from other sites because of CORS, so the request runs on the UtilityKit backend: it sends a HEAD request (retrying with GET if HEAD is refused or returns 405 or 501), follows up to eight redirects and reports the final response. You see the status code and reason, total response time in milliseconds, the hop count, the Server header, the final URL when a redirect happened, and every returned header in an alphabetical table. Set-Cookie, Cookie, Authorization and Proxy-Authenticate are removed before the result reaches you. A Raw JSON view lists each hop with its own status and headers. Only ports 80, 443, 8080 and 8443 are allowed, invalid TLS certificates fail the request, and private, loopback and link-local addresses are blocked.

Why use it

• Bypasses CORS Restrictions: Browsers block JavaScript from reading most cross-origin response headers. The server-side request returns the final response headers, minus cookie and authorization headers, without opening DevTools.

• Security Header Audit: Immediately surface the presence or absence of OWASP-recommended security headers — HSTS, CSP, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy — without running a dedicated scanner.

• Redirect Chain Visibility: The final URL and hop count expose unnecessary redirect chains — double HTTP-to-HTTPS hops, www-to-non-www redirects, and temporary-to-permanent redirect cascades that add latency for every visitor.

• Cache Header Diagnosis: Inspect Cache-Control, ETag, Last-Modified, Vary, and CDN-specific headers to verify caching policy is configured as intended and long-TTL immutable assets are marked correctly.

• Response Time Measurement: The millisecond response time shown is the server-side round-trip from the UtilityKit backend to the target URL — a useful baseline for comparing API endpoint performance or detecting degraded backends.

• No Tool Installation: Replaces a curl -I command or Postman request for quick header checks on any device with a browser. No local tool configuration, no authentication setup, no command memorization required.

How to use

1. Paste the full URL including the scheme — for example, https://example.com or https://api.example.com/health. It must be publicly reachable on port 80, 443, 8080 or 8443.
2. Click Fetch. The UtilityKit backend sends a HEAD request (falling back to GET if HEAD is refused) and follows up to eight redirects.
3. Read the three summary cards: status code and reason, total response time with the hop count, and the Server (or X-Powered-By) header. A Final URL note appears when the request was redirected.
4. Scan the alphabetically sorted header table for security headers such as strict-transport-security, content-security-policy, x-content-type-options, x-frame-options and referrer-policy; a missing header simply does not appear.
5. Open Raw JSON to see every redirect hop with its own status and headers, and select the text there to copy it into a report.

When it helps

• When auditing a site for security header compliance and you need to quickly verify whether HSTS, CSP, and X-Content-Type-Options are present before a penetration test or compliance review.
• When debugging a CDN caching issue — check whether Cache-Control returns public max-age=31536000 for static assets or no-store for dynamic API responses as configured.
• When troubleshooting a redirect loop or unexpected redirect chain — the hop count and final URL reveal whether a URL resolves cleanly or bounces through unnecessary intermediate hops.
• When verifying a Content-Security-Policy header after deployment to confirm the policy string matches the intended configuration and no syntax errors caused it to be silently dropped.
• When checking a third-party API or SaaS endpoint's response characteristics — server type, rate-limit headers, authentication challenge headers — without writing code to inspect them.
• When running a pre-launch checklist and confirming that the production server returns the correct headers for hashed CSS bundles (immutable), HTML pages (short revalidation), and API routes (no-cache).

Examples

URL: https://example.com

Status: 200 OK
Response time: 187 ms · 1 hops
Server: nginx

Response headers (6)
cache-control: max-age=3600, public
content-type: text/html; charset=utf-8
referrer-policy: strict-origin-when-cross-origin
server: nginx
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff

URL: http://www.example.com/old-page

Status: 200 OK
Response time: 312 ms · 3 hops
Final URL: https://example.com/new-page

Raw JSON chain:
301 http://www.example.com/old-page
301 https://www.example.com/old-page
200 https://example.com/new-page

Tips

• Check for the Strict-Transport-Security header and verify it includes max-age of at least 31536000 (one year) and preferably includeSubDomains and preload directives for full HSTS protection.
• A Cache-Control: public, max-age=31536000, immutable header on hashed static assets (CSS, JS) confirms the CDN will serve them without revalidation for a full year. If you see no-cache or short max-age on these assets, your CDN configuration is likely incorrect.
• The Server and X-Powered-By headers expose technology stack information. Many security hardening guides recommend removing or obfuscating these headers to avoid fingerprinting — if they appear, consider configuring your server to omit them.
• After deploying a Content-Security-Policy, use this tool to verify the exact CSP string that reaches browsers. A missing semicolon or typo in a directive causes the entire policy to silently fail in some browsers.
• Check the Vary header on CDN-served responses. Vary: Accept-Encoding is expected for compressed assets. Vary: Cookie or Vary: Authorization on public pages means every authenticated session gets a separate cache entry, which can degrade CDN efficiency significantly.

Frequently Asked Questions

Glossary

HTTP Response Header

Metadata sent by the server alongside an HTTP response that instructs the browser and intermediate proxies on how to handle the content — including caching, security policies, content type, and encoding.

Strict-Transport-Security (HSTS)

A security header that instructs browsers to always use HTTPS for a domain for the specified max-age duration, even if the user types an HTTP URL. Prevents SSL-stripping attacks.

Content-Security-Policy (CSP)

A security header that specifies which sources of scripts, styles, images, and other resources the browser is allowed to load for a page. A well-configured CSP is the primary defense against cross-site scripting (XSS).

Cache-Control

An HTTP header that controls how and for how long responses are cached by browsers and CDNs. Common values include no-cache, no-store, public max-age=N, and immutable.

X-Content-Type-Options

A security header with value nosniff that prevents browsers from MIME-sniffing a response away from its declared Content-Type. Stops certain class of content injection attacks.

SSRF (Server-Side Request Forgery)

A vulnerability where an attacker tricks a server into making HTTP requests to internal resources. Header checker tools mitigate this by blocking private IP ranges and localhost before making any outbound request.