HTTP Header Checker

Inspect HTTP headers of a given URL request/response to debug caching, security, and SEO issues. Analyze response headers for performance optimization and security best practices.

About HTTP Header Checker

An advanced HTTP header analysis tool that inspects and analyzes HTTP request and response headers from any URL. This tool helps debug caching issues, security configurations, SEO problems, and performance optimizations by providing detailed insights into server responses and client-server communications.

Why use a HTTP Header Checker?

HTTP headers control crucial aspects of web performance, security, and functionality, but they are often invisible and complex to analyze manually. This tool reveals hidden header information that affects caching, security policies, SEO rankings, and user experience, making it essential for web optimization and troubleshooting.

Who is it for?

Critical for web developers debugging server configurations, SEO specialists analyzing website headers, security professionals auditing HTTP security headers, and performance engineers optimizing caching strategies. Perfect for anyone who needs to understand and optimize HTTP communications.

How to use the tool

1

Enter the URL you want to analyze in the input field

2

Click check to retrieve and display the HTTP headers

3

Review response headers for caching, security, and performance settings

4

Analyze security headers like CSP, HSTS, and X-Frame-Options

5

Use the information to optimize server configuration and fix issues

Frequently Asked Questions

How do I check HTTP response headers?

Enter the target URL. The tool sends a request (HEAD by default, configurable to GET) via our backend, captures all response headers, and groups them by category: security headers (HSTS, CSP, X-Frame-Options), caching (Cache-Control, ETag, Last-Modified), CORS (Access-Control-*), content negotiation (Content-Type, Content-Encoding), redirects (Location, Status), and server metadata. Each header is annotated with its purpose and whether the value follows best practices.

What security headers should every site send?

Modern best practice. (1) **HSTS** (`Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`): forces HTTPS. (2) **CSP** (`Content-Security-Policy`): controls what resources can load — prevents XSS impact. (3) **X-Content-Type-Options: nosniff**: prevents MIME-type confusion attacks. (4) **X-Frame-Options: SAMEORIGIN** (or CSP `frame-ancestors`): clickjacking protection. (5) **Referrer-Policy: strict-origin-when-cross-origin**: limits referrer leakage. (6) **Permissions-Policy**: restricts browser features. Configure via [.htaccess Generator](/tools/htaccess-generator/) for Apache; equivalent Nginx config for Nginx.

Is the request sent to a server?

Yes — necessarily. Browsers expose only the response headers your own page received (the document's own headers); they don't expose headers from arbitrary cross-origin requests (CORS again). Our backend fetches the URL and forwards the headers verbatim. We don't store the URLs or headers; rate-limit log only. For private/staging URLs: use curl locally (`curl -I https://example.com`) — same output, never leaves your machine.

What do caching headers (Cache-Control, ETag) mean?

**Cache-Control** is the modern header for HTTP caching. Common directives: `public` (cacheable by any cache), `private` (only the browser's cache), `max-age=N` (cache for N seconds), `no-cache` (must revalidate before reuse), `no-store` (don't cache at all), `immutable` (resource never changes — never re-validate). **ETag**: a content hash; combined with `If-None-Match` on the next request, lets the server return 304 Not Modified (no body re-transmission). **Last-Modified**: a timestamp; paired with `If-Modified-Since` similarly. Use [HTTP Status Code Checker](/tools/http-status-code-checker/) for response code questions.

What headers reveal sensitive server information?

Avoid these in production. **Server** header (e.g., `Server: nginx/1.18.0`): reveals server software and version — useful for attackers targeting specific CVEs. **X-Powered-By** (e.g., `X-Powered-By: Express`): same issue for application framework. **X-AspNet-Version**, **X-Generator** (CMS hints): same issue. Disable or replace these (Nginx: `server_tokens off;`; Express: `app.disable('x-powered-by')`). Information disclosure is the cheapest reconnaissance for attackers — deny it free.

How do I check if HSTS is configured correctly?

Look for `Strict-Transport-Security` header in the response. Recommended value: `max-age=31536000; includeSubDomains; preload`. `max-age=31536000` = 1 year (browsers will refuse HTTP for that long). `includeSubDomains` = applies to all subdomains. `preload` = consent to be added to browsers' built-in HSTS preload list (submit at https://hstspreload.org). Pitfalls: short max-age (under a year — preload requires 1+ year); HSTS on an HTTP page (must be sent over HTTPS to be honored); preloading too early (hard to undo). After deployment, verify with [SSL Certificate Checker](/tools/ssl-certificate-checker/) for the broader HTTPS posture.

What's the right Content-Security-Policy?

Hard question with no universal answer. Start strict: `default-src 'self'` (only same-origin resources). Add specific allowances: `script-src 'self' https://cdn.jsdelivr.net` for trusted CDNs. Avoid `unsafe-inline` and `unsafe-eval` (defeat the purpose). Use `nonce-XXX` or `sha256-XXX` for inline scripts. Test in **Report-Only mode** first (`Content-Security-Policy-Report-Only`) to see what would break before enforcing. Use https://csp-evaluator.withgoogle.com/ to audit your policy. CSP is the most powerful XSS mitigation but the most complex to configure correctly.

How are CORS headers related?

CORS headers are a specific subset of HTTP response headers — `Access-Control-Allow-Origin`, `-Allow-Methods`, `-Allow-Headers`, `-Allow-Credentials`, `-Max-Age`. They're returned alongside the rest of the response (or as the only headers in an OPTIONS preflight response). For CORS-specific debugging, use [CORS Header Checker](/tools/cors-header-checker/) — it sends an OPTIONS preflight with a configurable Origin header, which this generic header checker doesn't do by default. Use this tool for general header inspection, CORS Header Checker for CORS-specific debugging.

Share This Tool

Found this tool helpful? Share it with others who might benefit from it!

💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.

Support This Project

Buy Me a Coffee