HTTP Header Checker
Free HTTP header checker for any URL. Inspect server, cache, security (HSTS, CSP, X-Frame-Options) and performance headers for security and QA review.
What is an HTTP Header Checker Tool?
An HTTP Header Checker opens a real HTTP or HTTPS connection to a URL and reads back the response headers the server actually serves. HTTP headers are the metadata layer of the protocol (RFC 7230 to 7237) and they carry a surprising amount of the server’s behaviour: how content is cached, what content types are allowed, what cross-origin policy applies and, importantly, which security headers are set.
Security headers are the part most people care about. HSTS keeps a site on HTTPS, CSP narrows what scripts can run, X-Frame-Options blocks clickjacking, and a few others protect against MIME sniffing, referrer leakage and protocol downgrade. This tool makes the request, reads the response, grades the security header set against OWASP and Mozilla guidance, and lays the rest of the headers out so you can scan them.
What Are HTTP Headers?
HTTP headers are fundamental components of web communication, serving as metadata that controls how browsers and servers interact. Our HTTP Header Checker focuses on response headers, which reveal server configuration, security posture, and content delivery settings. Response headers include security directives (HSTS, CSP, X-Frame-Options), caching policies (Cache-Control, ETag), content specifications (Content-Type, Content-Length), and server information (Server, X-Powered-By).
HTTP headers function identically in both HTTP (port 80) and HTTPS (port 443) connections, but HTTPS adds TLS/SSL encryption (RFC 8446) that protects headers from interception during transmission. HTTPS is essential for security headers like HSTS, which specifically require HTTPS connections to function effectively. It supports both protocols and handles TLS/SSL encryption automatically for HTTPS connections, ensuring accurate header analysis regardless of protocol.
How HTTP Header Analysis Works
HTTP header analysis involves establishing network connections, retrieving HTTP responses, parsing header data, and analyzing security configurations. This checker uses authoritative methods built on internet standards to provide accurate header information:
1. Connection Establishment and DNS Resolution
The tool resolves the target domain name to an IP address using DNS queries (A/AAAA records per RFC 1035), then establishes a TCP connection to port 80 (HTTP) or port 443 (HTTPS). For HTTPS connections, the tool performs a TLS handshake per RFC 8446 to establish an encrypted connection before sending HTTP requests.
Converts domain names to IP addresses using DNS queries (A/AAAA records) per RFC 1035 standards.
Establishes TCP connection to port 80 (HTTP) or port 443 (HTTPS) for HTTP communication.
Performs TLS/SSL handshake per RFC 8446 for HTTPS connections to establish encrypted communication.
Automatically detects HTTP or HTTPS protocol from URL and handles appropriate connection type.
Supports both IPv4 and IPv6 addresses. For IP addresses, the tool automatically adds http:// protocol and attempts connection. If HTTP fails, HTTPS is automatically tried as a fallback to ensure maximum compatibility.
SSL certificate verification is intentionally disabled, so you can inspect headers on servers with self-signed or otherwise broken certs. If you want to assess the certificate itself, use the SSL Certificate Checker instead.
Requests have a 15-second timeout to prevent indefinite waiting. If a server doesn't respond within this timeframe, the connection is terminated with an appropriate error message.
2. HTTP Request Transmission
The tool sends an HTTP request (typically GET or HEAD method) to the target server, including standard request headers such as Host, User-Agent, Accept, and Connection. The server processes the request and generates an HTTP response containing status codes, response headers, and optionally response body content.
Sends HTTP request using GET or HEAD method to retrieve response headers efficiently. The HEAD method is preferred when only headers are needed as it doesn't download the response body, making it faster and more bandwidth-efficient.
Sends browser-like request headers including User-Agent (Chrome), Accept, Accept-Language, Accept-Encoding, Upgrade-Insecure-Requests, Sec-Fetch-* headers, Cache-Control, and Connection to mimic real browser behavior and ensure accurate header retrieval.
Receives HTTP response containing status codes, response headers, and optional response body content.
Handles connection timeouts, DNS failures, and HTTP errors with appropriate error messages and graceful degradation.
3. Header Parsing and Security Analysis
The retrieved HTTP response headers are parsed and categorized into security headers, caching headers, content headers, server information headers, CORS headers, and custom headers. Each header is validated for syntax compliance per RFC 7230-7237 standards, and security headers are analyzed against OWASP Secure Headers Project recommendations and Mozilla security guidelines.
Parses HTTP response headers per RFC 7230-7237 standards and extracts header names and values.
Organizes headers into categories: Security, Content, Caching, Server Info, CORS, and Custom headers.
Recognizes modern header alternatives, such as CSP frame-ancestors as a replacement for X-Frame-Options. The tool analyzes both traditional and modern headers, giving preference to modern implementations when both are present.
Validates header syntax for compliance with HTTP standards per RFC 7230-7237 specifications.
Analyzes security headers against OWASP Secure Headers Project recommendations and Mozilla security guidelines.
Identifies missing security headers that indicate potential vulnerabilities and security gaps.
How to Use HTTP Header Checker
Our HTTP Header Checker is designed for users of all technical levels. Follow this straightforward process:
-
Step 1: Enter a domain name (e.g., example.com), full URL (e.g., https://example.com), or IP address (IPv4 like 192.168.1.1 or IPv6 like 2001:db8::1). The tool automatically detects the input type and protocol. For domains without a protocol, HTTPS is used by default. For IP addresses, HTTP is tried first, with HTTPS as a fallback if HTTP fails.
-
Step 2: Complete the CAPTCHA verification to ensure secure usage and prevent automated abuse.
- Step 3: Click on the "CHECK HEADERS" button. The tool will establish HTTP connection and retrieve headers.
Results include complete HTTP response headers organized by category (Security, Content, Caching, Server Info, CORS, Custom), security headers analysis comparing configurations against OWASP recommendations, missing security headers identification, and detailed security recommendations. You can view headers in organized sections, analyze security configurations, copy header values, or export complete results in JSON, CSV, or TXT formats.
What Are Critical Security Headers?
Security headers are HTTP response headers that protect websites and users from various attacks. Understanding these headers is crucial for maintaining secure web applications:
HTTP Strict Transport Security (HSTS)
Header:
Strict-Transport-Security (RFC 6797)Purpose: Forces browsers to use HTTPS connections, preventing protocol downgrade attacks and man-in-the-middle attacks.
Example:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Missing HSTS allows attackers to downgrade HTTPS connections to HTTP, intercepting sensitive data. HSTS ensures all connections use encryption, protecting user credentials and personal information.
Content Security Policy (CSP)
Header: Content-Security-Policy (RFC 7762)
Purpose: Mitigates Cross-Site Scripting (XSS) attacks by controlling which resources can be loaded and executed.
Example: Content-Security-Policy: default-src 'self'; script-src 'self'
Missing CSP leaves websites vulnerable to XSS attacks, allowing attackers to inject malicious scripts. CSP restricts resource loading, preventing unauthorized script execution.
X-Frame-Options
Header:
X-Frame-Options (RFC 7034)Purpose: Prevents clickjacking attacks by controlling whether pages can be displayed in frames.
Values:
DENY (no framing), SAMEORIGIN (same origin only)Example:
X-Frame-Options: DENY
Missing X-Frame-Options allows attackers to embed pages in malicious frames, tricking users into clicking hidden elements.
X-Content-Type-Options
Header:
X-Content-Type-Options: nosniffPurpose: Prevents MIME-type sniffing attacks by forcing browsers to respect declared content types.
Missing this header allows browsers to guess content types, potentially executing malicious content as scripts. The nosniff directive ensures browsers respect declared MIME types.
Referrer-Policy
Header: Referrer-Policy
Purpose: Controls how much referrer information is shared with requests, protecting user privacy.
Example: Referrer-Policy: strict-origin-when-cross-origin
Controls referrer information sharing, preventing sensitive URL parameters from being leaked to third-party sites.
X-XSS-Protection (Deprecated)
Header: X-XSS-Protection
Status: Deprecated - modern browsers have removed XSS filtering
Purpose: Was used to enable browser XSS filtering, but this feature has been removed from modern browsers.
Modern Alternative: Content-Security-Policy (CSP) provides superior XSS protection.
Do not rely on X-XSS-Protection. Implement a strict Content-Security-Policy instead. CSP is the modern way to block Cross-Site Scripting and gives you fine-grained control over which sources can run script in the browser.
Expect-CT (Deprecated)
Header: Expect-CT
Status: Deprecated (RFC 9163) - replaced by Certificate Transparency monitoring
Purpose: Was used to detect misissued SSL certificates through Certificate Transparency logs.
Note: This header is deprecated and should not be relied upon. Modern certificate monitoring uses Certificate Transparency logs directly.
Do not implement Expect-CT. Instead, use Certificate Transparency monitoring services or tools that query CT logs directly for certificate monitoring and security.
Security Header Scoring System
The security grade is a 100-point score inspired by securityheaders.com. Each header is checked for presence, configuration quality and alignment with current best practice:
Maximum 25 points. Base score for presence (6 points), bonus for max-age ≥ 1 year (up to 20 points), includeSubDomains directive (+3 points), and preload directive (+2 points). Excellent configuration with max-age ≥ 31536000, includeSubDomains, and preload receives full 25 points.
Maximum 25 points. Base score for presence (12 points), bonus for default-src directive (+4 points), script-src directive (+3 points), and nonce/hash usage (+6 points). Penalties for unsafe-inline (-3 points) and unsafe-eval (-2 points). Excellent CSP with strict policies receives up to 25 points.
Maximum 12 points. DENY receives 12 points, SAMEORIGIN receives 10 points. CSP frame-ancestors is also recognized as a modern alternative and receives 12 points. Missing both receives 0 points.
Maximum 12 points. Properly configured with "nosniff" receives 12 points. Missing or incorrectly configured receives 0-5 points.
Maximum 13 points. Properly configured with standard policy values receives 13 points. Stricter policies (strict-origin, strict-origin-when-cross-origin, same-origin, no-referrer) are preferred.
Maximum 13 points. Base score for presence (5 points), bonus for restricted features (up to 8 points). More restricted features indicate better security configuration.
Security Header Grade Scale Explained in Detail
We believe in transparency. Understanding how your security header configuration translates into a grade helps you make informed decisions about your website's security posture. Here is the detailed breakdown of our grading system:
Security Header Grades (7 grades)
Virtually perfect security header configuration. All critical security headers are present and properly configured with optimal settings. HSTS includes max-age ≥ 1 year, includeSubDomains, and preload. CSP uses strict policies with nonces/hashes and no unsafe directives. All other headers are optimally configured. This grade indicates enterprise-level security header implementation.
Excellent security header configuration with minor areas for improvement. Most critical headers are present and well-configured. May have slight deficiencies such as CSP without nonces/hashes, HSTS without preload, or minor configuration optimizations needed. This grade indicates strong security header implementation suitable for production environments.
Good security header configuration with room for improvement. Most security headers are present but may have suboptimal configurations. Common issues include CSP with unsafe-inline or unsafe-eval directives, HSTS with insufficient max-age, or missing some recommended headers like Permissions-Policy. This grade indicates acceptable security but requires optimization for better protection.
Fair security header configuration with significant gaps. Some critical headers may be missing or improperly configured. Common issues include missing CSP, weak HSTS configuration, or missing X-Frame-Options/X-Content-Type-Options. This grade indicates basic security measures are in place but critical improvements are needed to protect against common web attacks.
Poor security header configuration with major security gaps. Multiple critical headers are missing or misconfigured. Websites with this grade are vulnerable to common attacks including XSS, clickjacking, and protocol downgrade attacks. Immediate action is required to implement missing security headers and improve configurations.
Bad security header configuration with critical security vulnerabilities. Most security headers are missing or severely misconfigured. Websites with this grade are highly vulnerable to attacks and should not be used in production without immediate security header implementation. This configuration poses significant security risks to users.
Very bad security header configuration with minimal or no security protection. Critical security headers are completely missing or severely misconfigured. Websites with this grade are extremely vulnerable and should not be deployed to production. Immediate implementation of all critical security headers is required before going live.
Security Header Best Practices
Implementing security headers correctly is crucial for protecting websites and users from attacks. This section provides best practices based on OWASP recommendations and identifies common misconfigurations:
Always implement HSTS with appropriate max-age (minimum 31536000 seconds for one year) and includeSubDomains directive. Missing HSTS makes websites vulnerable to protocol downgrade attacks.
Implement strict CSP policies restricting resource loading to trusted sources only. Use default-src 'self' as baseline and avoid 'unsafe-inline' and 'unsafe-eval' directives when possible. Weak CSP policies using these directives provide minimal protection against XSS attacks.
Use DENY to prevent all framing, or SAMEORIGIN to allow same-origin framing only. Alternatively, use Content-Security-Policy frame-ancestors directive (e.g., frame-ancestors 'none' or frame-ancestors 'self'), which is the modern replacement for X-Frame-Options. CSP frame-ancestors provides more granular control and is preferred over X-Frame-Options. Missing X-Frame-Options or CSP frame-ancestors makes websites vulnerable to clickjacking attacks.
Always set to nosniff to prevent MIME-type sniffing attacks. This ensures browsers respect declared content types, preventing content type confusion attacks.
Remove or minimize Server header to prevent information disclosure. Revealing server software and version information (e.g., Server: nginx/1.18.0) helps attackers identify vulnerabilities and plan targeted attacks.
Remove X-Powered-By header to prevent application framework disclosure. Revealing framework information (PHP, Express, etc.) helps attackers identify framework-specific vulnerabilities. Remove this header in production environments.
Review custom X-* headers for information disclosure. Custom headers may reveal internal application details, API endpoints, or system architecture information. Remove or sanitize headers that disclose sensitive information.
Implement appropriate Referrer-Policy to protect user privacy. Use strict-origin-when-cross-origin for balanced privacy and functionality, or no-referrer for maximum privacy. This prevents sensitive URL parameters from being leaked to third-party sites.
Use appropriate cache directives: no-store for sensitive content, public, max-age=3600 for static resources, and private for user-specific content. Misconfigured Cache-Control headers can cause security issues (caching sensitive content) or performance problems.
Common HTTP Header Checker Use Cases
The most common reasons people reach for a header checker:
Verify security header implementation for compliance with OWASP recommendations, PCI-DSS requirements, and security standards. Identify missing security headers that indicate potential vulnerabilities and assess security posture for risk management.
Analyze caching headers (Cache-Control, ETag, Expires) to optimize content delivery and reduce server load. Identify caching misconfigurations that impact performance and optimize cache policies for better user experience.
Debug CORS issues by analyzing Access-Control-Allow-Origin headers and related CORS directives. Identify CORS misconfigurations that block cross-origin requests and verify CORS policies for security compliance.
Verify server software identification, analyze custom application headers, and identify information disclosure vulnerabilities. Check server header configurations for security best practices.
Features and Capabilities
What you get, in one place. Useful for both engineering and non-technical users:
Supports both HTTP (port 80) and HTTPS (port 443) connections with proper TLS/SSL handling per RFC 8446 standards, ensuring compatibility with all web servers.
Establishes live HTTP connections to retrieve current header information directly from target servers, ensuring up-to-date and accurate header data.
Analyzes security headers against OWASP Secure Headers Project recommendations and Mozilla security guidelines, identifying missing headers and providing security recommendations.
Organizes headers into logical categories (Security, Content, Caching, Server Info, CORS, Custom) for easy analysis and understanding.
Allows exporting header information in JSON (RFC 8259), CSV, and TXT formats for documentation, analysis, and integration with other systems.
All header checks are performed in real-time with no data storage, ensuring your header information remains private and secure. We do not retain or log domain names, URLs, headers, or lookup results.
Frequently Asked Questions (FAQ)
Header checking surfaces what the server is actually telling clients: which security headers are set (and how strictly), the caching policy, the declared content type, server identification banners, CORS rules and any custom application headers. Useful for spotting security gaps, debugging cache behaviour, tracking down a misconfigured CDN and confirming the headers your compliance program expects to see.
Security headers protect websites and users from various attacks including XSS (Cross-Site Scripting), clickjacking, MIME-type sniffing, protocol downgrade attacks, and man-in-the-middle attacks. Missing security headers indicate potential vulnerabilities that attackers can exploit. Security headers like HSTS, CSP, X-Frame-Options, and X-Content-Type-Options provide essential protection layers, preventing common web attacks and protecting user data.
HTTP headers work identically in both HTTP (port 80) and HTTPS (port 443) connections. HTTPS adds TLS/SSL encryption (RFC 8446) to HTTP, protecting header data from interception during transmission. Security headers like HSTS are specifically designed for HTTPS connections, forcing browsers to use encrypted connections. The checker supports both protocols and handles TLS/SSL encryption automatically.
No, our HTTP Header Checker tool does not store domain names, URLs, HTTP headers, or lookup results in our application database. All header checks are performed in real-time exclusively for the duration of your request and are immediately discarded. Standard server access logs may still be created as described in our Privacy Policy.
HTTP headers may reveal server software versions, application frameworks, and custom application details through Server, X-Powered-By, and custom X-* headers. This information disclosure can help attackers identify vulnerabilities and plan targeted attacks. It identifies information disclosure headers and recommends removing or minimizing them to prevent sensitive information leakage.