Security headers
F40/100
HSTS passes. Missing CSP fails; missing framing protection, Referrer-Policy, nosniff, Permissions-Policy, and COOP are warnings. Missing COEP is informational.
HTTP Header Checker
Free, no signup. See the headers browsers and crawlers receive: every redirect hop, separate security and SEO grades, edge fingerprints, compression, and an honest HTTP/3 signal.
This makes two user-triggered requests for one URL from Cloudflare infrastructure. It compares user-agent responses, not verified crawler behavior or crawler IP access.
Compare staging or another URL
The report compares the final response headers from two independent checks.
Checks run from our server; we fetch the URL you enter and don't keep the results. Complete response header maps are returned to your browser. Repeating the same URL and user-agent within about ten minutes may reuse a short-lived edge cache. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Compare common headers across up to five URLs
Frequency is calculated in this browser from the live final responses in this run. It is not a global popularity dataset.
| Header | Responses | Frequency | Registry status |
|---|
Sample report
Illustrative example — exact grading for the fixed header map below
HTTP/2 200
strict-transport-security: max-age=31536000
cache-control: public, max-age=3600
etag: "abc123"SEO headers
A+100/100
Cache-Control and ETag pass. Missing X-Robots-Tag, Link canonical, and Vary are informational in this HTTP-only grade.
The displayed HTTP/2 line is illustrative input only: the live Worker cannot expose the negotiated HTTP version.
How to use it
- Enter a public URL and choose the browser, search-crawler, or AI-crawler user-agent you want to send.
- Optionally add a staging or comparison URL; only final-response headers are diffed.
- Choose Check headers, start with the two grades, then inspect the exact finding and header evidence.
- Review every redirect response and use the raw curl-style view when you need to copy the complete observed map.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Delivery & transfer facts
Cache diagnostics
Changed final-response headers
Redirect chain & complete headers
Raw curl-style header view
Rate this tool
What the results mean
- Security grade deducts 20 points per failure and 8 per warning across the implemented header rules.
- SEO grade evaluates X-Robots-Tag, Link canonical and hreflang, Vary, cache directives, and ETag.
- Pass confirms one rule; info is context without a score penalty.
- Delivery fingerprint is evidence about a public edge, not proof of the origin host.
- Comparison lists changed final-response header values, not HTML or behavior differences.
How it works
A bounded server-side checker sends the selected user-agent, records each redirect response without hiding intermediate headers, and returns normalized header maps and timings. Browser-side functions grade the final response, parse Link headers, inspect compression and protocol advertisements, identify a small set of edge fingerprints, produce a curl-style view, and diff an optional second final response. The small batch mode counts fields only across the final responses fetched in that run and labels names from a local status-preserving snapshot of the IANA HTTP Field Name Registry.
Features
- Complete headers for every observed redirect hop.
- Separate deterministic security and HTTP-level SEO grades.
- Browser, Googlebot, and supported crawler user-agent choices.
- Compression, edge fingerprint, and honest HTTP/3 advertisement facts.
- Optional final-response environment diff and raw header export view.
- Session-local common-header frequency for up to five URLs.
Limitations
The report cannot expose negotiated HTTP version, TLS certificate details, private origin infrastructure, or headers added only inside a user's network. The Fetch Headers API may combine repeated field lines: parsed combined values are assessed, but the original field-line order and boundaries cannot be reconstructed. User-agent strings originate from a Cloudflare datacenter, not verified crawler IP ranges. It does not inspect HTML metadata, application security, or whether a 200 body is correct.
Frequently asked questions
Does the tool preserve repeated header field lines?
Not exactly. The Worker Fetch Headers API exposes a normalized, potentially combined value. The checker parses and assesses that combined value, but it cannot reconstruct the original order or boundaries of repeated field lines.
Does this show the HTTP version?
Workers do not expose the negotiated HTTP version. The tool only reports when Alt-Svc advertises HTTP/3; that is not proof this request used HTTP/3.
Why do browser and Googlebot results differ?
Sites can vary headers by user-agent. This sends the selected user-agent string from a Cloudflare datacenter, not from a verified crawler IP rangeA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index..
Are URLs saved?
No. The URL is fetched to build this report and a short-lived edge cache may reuse the same URL and user-agent response for about ten minutes.
Is a high security-header grade proof that a site is secure?
No. The grade covers a defined set of public response headers. It does not test application vulnerabilities, authentication, server configuration, dependency risk, or whether a policy works correctly for the application.
Does the SEO grade inspect HTML canonical and robots tags?
No. It evaluates HTTP-level signals such as X-Robots-TagThe X-Robots-Tag is an HTTP response header that carries the same indexing and serving directives as the robots meta tag (noindex, nofollow, nosnippet, and the rest). Because it lives in the header rather than the HTML, it's how you control indexing for non-HTML files like PDFs, images, and videos. and Link headers. Page-level canonical and robots elements require an HTML-aware checker.
Feature requests for Http Header Checker
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
See what happens before the final page loads
Inspect every observed redirect response and the final response so an intermediate hop does not hide an important status or header.
Review security-header basics
Check a defined set of public response headers, understand each pass or recommendation, and keep the grade separate from a full security audit.
Check HTTP-level SEO and caching signals
Review X-Robots-Tag, Link canonicals and hreflang, Vary, Cache-Control, validators, compression, and observable cache evidence.
Compare production with staging or a crawler view
Diff final-response headers between two URLs or between a browser and selected crawler user-agent without treating the request as verified crawler behavior.
Create a repeatable technical handoff
Use exact findings, raw headers, a share link, a grade card, and an explicit re-check to document what changed and verify the fix.
Watch the full workflow
HTTP Header Checker walkthrough
Read the transcript
HTTP Header Checker
Response headers are small instructions a website sends before the visible page. They can affect redirects, caching, browser protections, and crawler handling. I’ll show you how to inspect them, understand the grades, compare production with staging, and verify a change. Every result in this walkthrough is repeatable fictional example data.
Step 1
When a browser or crawler asks for a U-R-L, the server returns a status, response headers, and usually a page body. Headers are the metadata part. This tool shows the headers for every observed redirect and grades a defined set of security, search, and caching signals.
Step 2
Use it to inspect redirect hops, review security-header basics, check H-T-T-P-level search signals, compare staging with production, compare user-agent responses, or create evidence for a developer. It answers what this public request returned. It does not inspect the application behind the response.
Step 3
Enter one public U-R-L. “Browser” is selected by default. You can instead send a supported crawler user-agent string, compare that crawler response with the browser response, or open “Compare staging or another URL” to compare two final responses. A user-agent string does not make the request come from a verified crawler network.
Step 4
Our primary address is a fictional production trail guide. The comparison address is its fictional staging version. This is a useful release check: the production page is the reference, and the second result tells us which final-response headers would change if staging went live.
Step 5
Choose “Check headers.” The tool makes two bounded, user-triggered requests through the site’s checker. It waits for each redirect chain, then shows the primary grades and a separate final-header comparison. The example returns immediately because the captured responses are fixed fixtures.
Step 6
The summary says two responses were inspected: one redirect and one final page. The freshness line records when this response set was fetched and whether it came from the short-lived cache. Below that, the security and search grades are kept separate so one score cannot hide the other.
Step 7
The security grade is A plus for this fixture. Each row names the check, explains why it passed or needs action, shows the exact observed value, and names the final response as its source. An informational row has no score penalty. Even an A plus only covers these header rules; it cannot prove the application is secure.
Step 8
The H-T-T-P-level S-E-O grade is also A plus. It sees a Link-header canonical, a specific Vary value, Cache-Control, and an E-Tag validator. “No X-Robots-Tag” is context, not an error. This grade does not read the H-T-M-L canonical or meta robots tag inside the page.
Step 9
The delivery facts show Brotli compression, an H-T-T-P three advertisement, and a Cloudflare fingerprint from the C-F Ray header. “Advertises” is the key word: the Worker cannot tell which protocol this request negotiated. A C-D-N fingerprint describes the public edge and does not prove where the origin server lives.
Step 10
Cache-Control describes policy, but policy alone does not prove a cache hit. Here, Age is eighteen and C-F Cache Status is H-I-T, which are stronger observations for this response. E-Tag and Last-Modified can support revalidation. Vary tells caches which request fields may create a different version.
Step 11
The staging comparison lists only changed final-response header values. Production has H-S-T-S, a content security policy, validators, and a canonical Link header. Staging adds noindex, uses no-store, and sends Vary star. This is a focused header diff; it does not compare H-T-M-L, scripts, or page behavior.
Step 12
The first hop is status three-oh-one. It sends the request from the non-W-W-W address to the final W-W-W address. The row keeps that intermediate response’s timing, Location, cache policy, and H-S-T-S header visible. This prevents the final page from hiding what happened earlier.
Step 13
The second hop is the final two-hundred response. This complete normalized map is the evidence used for the grades, delivery facts, and cache diagnostics. The Worker may combine repeated header field lines, so the original line order and boundaries cannot be reconstructed.
Step 14
Open “Raw curl-style header view” for a plain-text record of every observed hop. It is formatted like command-line header output, which makes it easy to copy into a ticket. The status line is deliberately called H-T-T-P response because the Worker cannot expose the negotiated H-T-T-P version.
Step 15
For a crawler comparison, select “Googlebot” and enable “Compare browser response with the selected crawler user-agent.” This makes two requests for the same U-R-L: one browser string and one Googlebot string. It detects response variation, but it does not verify crawler I-P access.
Step 16
Run the comparison and here’s the payoff. Both variants return two-hundred, but the fixture changes Cache-Control, adds User-Agent to Vary, and sends noindex to the Googlebot string. That is a strong review cue. It is not proof that verified Googlebot receives the same response from its own network.
Step 17
The small batch mode compares up to five U-R-Ls. Our three final responses all contain Cache-Control, Content-Encoding, Content-Type, Vary, and nosniff. Other fields appear in two of three. Frequency describes only this run, and the registry column distinguishes registered field names from unknown extensions.
Step 18
“Download grade card” creates a compact visual summary. “Copy share link” keeps the selected input state in the address. After a fix, “Re-check now” explicitly bypasses the tool’s short-lived cached response, then updates the freshness label so you know which observation you are reviewing.
Step 19
The checker cannot expose the negotiated H-T-T-P version, reconstruct repeated field lines, audit application vulnerabilities, or prove an origin host. A matching crawler string is not crawler authentication. The results are also one point-in-time fetch from Cloudflare infrastructure, so verify important differences from the relevant environment and network.
Turn the header report into a fixing list
Start with the exact response and header behind a finding. Make the smallest appropriate server or C-D-N change, then use “Re-check now” to confirm the new response. Keep the report in perspective: it is strong public header evidence, but it is not a full security audit or a promise about crawling and indexing.
Common issues & how to fix them
- Error HSTS is missing Fix: Serve Strict-Transport-Security on HTTPS responses, starting with a tested max-age and expanding to includeSubDomains only when every subdomain is HTTPS-ready.
- Warning HSTS lifetime is short Fix: Raise Strict-Transport-Security max-age to at least 31,536,000 seconds after confirming HTTPS works across the covered hosts.
- Error Content Security Policy is missing Fix: Add a Content-Security-Policy that allowlists the scripts, styles, images, frames, and connections the page actually needs, then tighten it from report-only to enforcement.
- Warning Framing protection is missing Fix: Set Content-Security-Policy frame-ancestors to the origins allowed to embed the page, or use X-Frame-Options: DENY when embedding is never allowed.
- Warning Referrer-Policy is missing Fix: Set Referrer-Policy to strict-origin-when-cross-origin, or a stricter policy that still supports the site’s analytics requirements.
- Warning Referrer policy leaks full URLs Fix: Replace unsafe-url or origin-when-cross-origin with strict-origin-when-cross-origin so cross-origin requests do not expose full paths and query strings.
- Information Cross-Origin Embedder Policy is missing Fix: If the page needs cross-origin isolation, set Cross-Origin-Embedder-Policy: require-corp and ensure every embedded cross-origin resource opts in; otherwise document that isolation is not required.
- Error Multiple HTTP canonicals are present Fix: Emit exactly one HTTP Link header with rel="canonical" for the preferred URL and remove conflicting canonical targets at the edge or origin.
- Error Vary star prevents useful caching Fix: Replace Vary: * with only the request headers that actually change the response, such as Accept-Encoding or Accept-Language, so caches can reuse it.
- Warning Response varies by user agent Fix: Stop varying the full response on User-Agent where possible; use feature detection or a narrowly normalized device signal and confirm crawlers receive equivalent primary content.
- Warning Googlebot receives restrictive caching Fix: Remove no-store/private caching sent specifically to Googlebot unless the content is genuinely personalized, and return the same cacheable public representation users receive.
- Information Cache-Control is absent Fix: Set an explicit Cache-Control policy appropriate to the resource, using public max-age/s-maxage for reusable content or no-store for truly sensitive responses.
- Information ETag is absent Fix: Add a stable ETag or Last-Modified validator for cacheable responses so clients can revalidate without downloading unchanged content.
- Error X-Robots-Tag blocks indexing Fix: Remove noindex from the X-Robots-Tag on URLs intended for search, then verify the final response and request recrawling.