What does the HTTP Header Checker analyze?

The tool makes a full HTTP request to your URL and analyzes everything that comes back. It reports the status code and protocol version (HTTP/1.1 or HTTP/2), then runs a 20+ point automated audit covering security headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options), performance settings (compression, caching directives), and TLS configuration (protocol version, cipher strength). A timing waterfall breaks the connection into four phases: DNS lookup, TCP connect, TLS handshake, and Time to First Byte. The TLS card shows certificate details including issuer, subject, expiry countdown, Subject Alternative Names, protocol version, and cipher suite. All response and request headers are listed with colored badges highlighting security-relevant ones. Body metadata shows wire size versus decoded size with the compression ratio. Every flagged issue comes with actionable fix instructions and copy-pasteable server configs for Nginx, Apache, and Cloudflare.

What is TTFB and why does it matter?

TTFB (Time to First Byte) measures the time from sending the HTTP request until the first byte of the response arrives. Once DNS, TCP, and TLS are done, TTFB captures what is left: server-side processing. That includes application code execution, database queries, template rendering, cache lookups, and starting the response stream. A TTFB over 800ms usually points to slow server-side logic, unoptimized queries, missing application-level caching, or an overloaded origin server. Google factors server response time into Core Web Vitals and recommends keeping TTFB under 800ms, with excellent performance at under 200ms. Reducing TTFB typically involves server-side caching (Redis, Memcached), proper Cache-Control headers for HTTP-level caching, a CDN serving cached responses from edge locations closer to users, database query optimization with proper indexing, or moving to a faster application runtime. Of these, caching and CDN placement usually deliver the biggest improvements.

What security headers does the analysis check?

The analysis checks 8 security-related response headers. Strict-Transport-Security (HSTS, defined in RFC 6797) forces browsers to use HTTPS for all future requests, blocking protocol downgrade attacks and cookie hijacking. Content-Security-Policy (CSP, W3C Level 3) prevents XSS and code injection by specifying which content sources the browser should trust. X-Frame-Options stops clickjacking by controlling whether the page can load in iframes. X-Content-Type-Options with nosniff prevents MIME confusion attacks where browsers might execute a file as the wrong content type. Referrer-Policy controls how much URL information leaks to third-party sites. Permissions-Policy restricts access to browser APIs like camera, microphone, geolocation, and payment. The Server header gets checked for version information that helps attackers identify specific software vulnerabilities. X-Powered-By is flagged for technology stack exposure. Each missing or misconfigured header includes fix instructions with configuration examples for common servers.

How do I interpret TLS certificate information?

The TLS card shows the full certificate chain details for verifying your HTTPS setup. The issuer field identifies the Certificate Authority that signed the cert (trusted public CAs include Let's Encrypt, DigiCert, Sectigo, and Cloudflare). The subject shows your domain's Common Name. Validity dates display the Not Before and Not After timestamps with a countdown of days until expiry. The protocol version tells you whether the connection used TLS 1.2 or TLS 1.3. TLS 1.3 is preferred for its faster handshake and stronger security. The cipher suite shows the specific encryption algorithm negotiated, like AES-256-GCM or ChaCha20-Poly1305. Subject Alternative Names list every hostname the certificate covers, including wildcard entries. Warning badges appear automatically for common problems: expired certificate, not-yet-valid certificate, self-signed (not from a trusted CA), weak signature algorithm like SHA-1, or a hostname mismatch where the requested domain is not in the SANs.

What is ALPN and what do the protocol badges mean?

ALPN (Application-Layer Protocol Negotiation) is a TLS extension (RFC 7301) that lets client and server agree on the application protocol during the TLS handshake itself. Before ALPN existed, protocols like HTTP/2 needed an Upgrade header or the NPN extension, which added an extra round trip. The protocol badges in the results give you a quick overview of connection capabilities. The HTTP version badge shows 1.1 or 2 based on the response. The ALPN badge shows the negotiated identifier: h2 for HTTP/2 over TLS, h3 for HTTP/3 over QUIC, or http/1.1 for HTTP/1.1. The TLS badge shows either TLSv1.2 or TLSv1.3. The compression badge indicates the content encoding: gzip, br for Brotli (typically 15-20% better compression than gzip), or zstd for Zstandard. No compression badge means the response was sent uncompressed, which is worth fixing for text-based content types.

What does wire size vs decoded size mean?

Wire size is how many compressed bytes actually crossed the network. Decoded size is the uncompressed size after the client decompresses the response using the algorithm specified in the Content-Encoding header. When the server uses gzip, Brotli, deflate, or Zstandard compression, wire size is smaller than decoded size because the body is compressed in transit. The Body card shows both values and the compression ratio as a percentage. A 100 KB page compressed to 25 KB displays as 75% compression. Brotli typically beats gzip by 15-20% for text-based content. If wire size equals decoded size, the response was sent uncompressed. The analysis flags this as a performance issue when the Content-Type is compressible (text/html, text/css, application/javascript, application/json, image/svg+xml, application/xml). To fix it, configure your web server or CDN to compress responses for these content types. Most modern web servers and CDNs support Brotli out of the box.

Why is the DNS lookup time zero or very low?

A near-zero DNS lookup means the result was already cached somewhere in the resolver chain: the inspection server's local cache, an upstream recursive resolver like Cloudflare 1.1.1.1 or Google 8.8.8.8, or the OS stub resolver. This is completely normal for popular domains. Their records stay cached across resolver infrastructure worldwide because of frequent queries. DNS caching duration is controlled by the TTL (Time to Live) value that the domain administrator sets on each record, typically 300 seconds for records that change often up to 86400 seconds for stable production records. You will see higher DNS times when checking brand-new domains, domains with very low TTLs (under 60 seconds), or domains recently migrated to new nameservers. In those cases, the query has to traverse the full resolution chain from root servers through TLD nameservers to the authoritative server. Typical uncached resolution takes 20-80 milliseconds depending on geographic distance to the authoritative nameserver.

How is the overall grade calculated?

The analysis runs 20+ checks across four categories: security headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Server, X-Powered-By), performance (compression, caching, HTTP/2), TLS configuration (protocol version, cipher strength, certificate validity), and response quality (status code, content type, encoding). Each check gets rated as pass, warning, error, or info. The overall grade depends on the highest-severity finding. Excellent means zero errors or warnings. Good means no errors with only 1-2 minor warnings. Fair means 1 error that should be addressed. Needs Work means 2+ errors need attention. Below the grade, the Recommendations panel lists every fixable issue sorted by severity. Each recommendation includes copy-pasteable server config snippets for Nginx, Apache, and Cloudflare. If you want a deeper security-focused analysis with A+ to F letter grading, the dedicated HTTP Security Headers tool provides more granular scoring.

How do response headers relate to security?

Response headers are how servers tell browsers what security policies to enforce. They control how the browser handles page content and restrict dangerous behaviors. The inspector marks all security-relevant headers with colored badges so you can spot them immediately. HSTS prevents protocol downgrade attacks. CSP prevents cross-site scripting by whitelisting trusted content sources. X-Frame-Options blocks clickjacking by preventing iframe embedding. X-Content-Type-Options stops MIME sniffing attacks. Referrer-Policy limits URL leakage to third parties. Permissions-Policy restricts browser API access (camera, microphone, geolocation). Cross-Origin headers like COOP, COEP, and CORP provide process isolation against Spectre-class side-channel attacks. Missing critical headers like HSTS and CSP leave your site open to downgrade attacks, XSS injection, and data theft. For a full security header audit with A+ to F grading and auto-generated server configurations, the dedicated DNS Checker HTTP Security Headers tool goes deeper.

HTTP Header Checker

Inspect any URL's response headers, TLS certificate, request timing waterfall, and body metadata. Get automated security and performance analysis with actionable fix recommendations.

Quick Presets

HTTP Method

Accept-Encoding (Compression)

User-Agent

Accept (Content Type)

Cache-Control

Connection

Conditional Requests (Caching Test)

If-None-Match (ETag)

If-Modified-Since

Origin & Referrer (CORS / Hotlink Testing)

Origin

Referer

Authentication & Session

Not saved to browser storage

Username (HTTP Basic Auth)

Password (HTTP Basic Auth)

Authorization Header

Custom Headers

Add custom headers to test X-Forwarded-For, X-Real-IP, X-Custom-Header, etc.

“HTTP headers are the conversation between browser and server that nobody sees. Until something goes wrong.”

Written by Ishan Karunaratne · Last reviewed: March 11, 2026

How Does the HTTP Header Checker Work?

The HTTP Header Checker makes a single request to your URL and captures everything that happens during the connection: DNS resolution, TCP handshake, TLS negotiation, and the server's response. It then runs a 20+ point automated analysis across security headers, performance metrics, TLS configuration, and response quality — grading the overall result and flagging issues with specific fix instructions.

Every issue includes copy-pasteable server configurations for Nginx, Apache, and Cloudflare so you can fix problems immediately. Security-relevant response headers are annotated with colored badges for instant identification. The timing waterfall uses color-coded thresholds so you can spot bottlenecks at a glance.

What Does HTTP Inspection Reveal?

Every HTTP response carries far more information than the visible web page. The status code tells you whether the server handled the request successfully or encountered an error. Response headers carry security policies, caching directives, server software details, and content negotiation metadata. The TLS certificate tells you who vouches for the server's identity and how long that trust is valid. The timing breakdown reveals exactly where time is being spent — in DNS resolution, TCP handshaking, TLS negotiation, or server processing.

Together, these signals let you diagnose performance bottlenecks, verify security configurations, audit header policies, and confirm that certificates are valid and correctly configured — all from a single request.

What Does the Timing Waterfall Show?

DNS Lookup

Time to resolve the hostname to an IP address using DNS. A cached result returns in under 1 ms. An uncached query to an authoritative nameserver typically takes 20–80 ms. Use a low DNS TTL during migrations and a higher TTL (3600 s or more) for stable production records.

TCP Connect

Time to complete the three-way TCP handshake (SYN, SYN-ACK, ACK). This is primarily determined by network round-trip time (RTT) between the inspection server and your origin. Serving from a CDN edge node close to users dramatically reduces this value.

TLS Handshake

Time for SSL/TLS negotiation — key exchange, certificate verification, and cipher agreement. TLS 1.3 (current standard) requires only one round trip vs two for TLS 1.2, making it meaningfully faster. TLS session resumption and 0-RTT in TLS 1.3 can reduce this to near zero for repeat connections.

Time to First Byte (TTFB)

Time from the request being sent until the first byte of the response arrives. This captures server-side processing: application code execution, database queries, template rendering, and cache lookups. This is the metric you control most directly through application optimisation and caching strategy. Google's recommended threshold is under 800 ms, with excellent performance under 200 ms.

How Do You Read TLS Certificate Details?

A TLS certificate binds a domain name to a public key and is signed by a Certificate Authority (CA) that browsers trust. The inspector shows the full certificate chain details so you can verify the certificate is from a trusted issuer, covers the correct hostnames via Subject Alternative Names (SANs), and has sufficient time before expiry.

Certificates are automatically flagged if they are expired, not yet valid, self-signed (not signed by a trusted CA), or have a hostname mismatch (the domain you requested is not listed in the SANs). Any of these conditions will cause browsers to show a security warning and block users.

Modern certificates from public CAs like Let's Encrypt, DigiCert, and Sectigo are valid for 90 days to 1 year. Set up automatic certificate renewal at least 30 days before expiry to avoid service interruptions.

Security header gradingGet an A+ to F grade with config snippets for major servers.Redirect chain traceFollow every hop with TLS validity.Page speed testCore Web Vitals plus prioritized fixes.Robots.txt validatorCrawl access rules and sitemap directives.

HTTP Header Checker

“HTTP headers are the conversation between browser and server that nobody sees. Until something goes wrong.”

How Does the HTTP Header Checker Work?

What Does HTTP Inspection Reveal?

What Does the Timing Waterfall Show?

DNS Lookup

TCP Connect

TLS Handshake

Time to First Byte (TTFB)

How Do You Read TLS Certificate Details?

What Other Tools Help With HTTP Analysis?

HTTP Security Headers

Redirect Checker

DNS Inspector

Security Scanner

On-Page SEO Auditor

Frequently Asked Questions

HTTP Header Checker

“HTTP headers are the conversation between browser and server that nobody sees. Until something goes wrong.”

How Does the HTTP Header Checker Work?

What Does HTTP Inspection Reveal?

What Does the Timing Waterfall Show?

DNS Lookup

TCP Connect

TLS Handshake

Time to First Byte (TTFB)

How Do You Read TLS Certificate Details?

What Other Tools Help With HTTP Analysis?

HTTP Security Headers

Redirect Checker

DNS Inspector

Security Scanner

On-Page SEO Auditor

Related tools you might need

Frequently Asked Questions

What does the HTTP Header Checker analyze?

What is TTFB and why does it matter?

What does the timing waterfall show?

What security headers does the analysis check?

How do I interpret TLS certificate information?

What is ALPN and what do the protocol badges mean?

What does wire size vs decoded size mean?

Why is the DNS lookup time zero or very low?

How is the overall grade calculated?

How do response headers relate to security?