An HTTP headers checker shows the metadata a web server returns for a URL. Screpy makes one public GET request, follows supported redirects and lists the final response's header names and values without downloading the page body. Use the report to investigate a redirect, check a header change after deployment or locate an unexpected indexing instruction.
Start with the response you received, then compare it with what that resource should return. A successful check can reveal a server error or an unsuitable policy; a green result does not certify security, caching performance or search indexation.
Check the exact URL and its response chain
Enter a complete public HTTP or HTTPS address, including the relevant path and query. A homepage, PDF and product page can return different headers on the same domain. For a fictional product page, https://example.com/products/blue-mug/ is a more useful input than the site's root when that product response is what you need to inspect.
Read the response chain before the header table. A redirect can change the scheme, host or path; the table contains the final response's headers, not all headers from every step. The chain also includes the final response, so the number of displayed steps need not equal the number of redirects.
Confirm that the final URL is the resource you meant to check. A login page, error page or different hostname may explain unexpected values. Use Redirect Checker when you need a more focused investigation of the redirect path rather than the final header list.
Read an HTTP response header example
This fictional response illustrates how separate fields answer different questions. It is not a captured scan or a configuration to copy onto every page.
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Robots-Tag: noindex
The 200 status indicates a successful response. Content-Type declares HTML with UTF-8 encoding. Cache-Control describes caching instructions, while X-Robots-Tag gives an indexing instruction. A working response can therefore include a noindex directive: HTTP success does not mean the page is intended for search results.
The table displays normalized lowercase header names; capitalization does not make them different fields. The MDN header reference distinguishes request fields from response fields. This checker shows the response, not a dump of the cookies, browser preferences or authentication details from your own browsing session.
Review caching and indexing as separate decisions
Filter the table by a header name when investigating a specific problem. First decide what the resource needs: frequently changed HTML, a versioned asset and a deliberately excluded document need not share one policy.
| Header | Useful question for your review |
|---|---|
content-type |
Does the declared format match the resource you expected, or did a redirect reach a different response? |
cache-control |
Does the cache policy fit this resource's update and privacy requirements? |
etag or last-modified |
Is a validator present for conditional requests? Presence alone does not test revalidation. |
vary |
Which request-header differences does the response identify for cache selection? |
x-robots-tag |
Is an observed noindex instruction intentional for this URL? |
no-cache does not mean “never store”. It allows storage but requires validation before reuse. no-store instructs caches not to store the response. MDN's Cache-Control reference explains the distinction. This check does not measure cache hits or remove already cached copies.
An indexing directive is a separate decision from freshness. If an indexable page unexpectedly returns noindex, locate the responsible application, server or response rule before changing it. Use Noindex Checker to inspect HTML directives as well. Google's noindex documentation describes the instruction; observing it does not establish Google's current index state.
Understand the security-header observations
Screpy highlights selected declarations for review. Treat a finding as a configuration question, not an exploit report or a recommendation to paste an unfamiliar policy into production.
| Observation | What the check does and does not establish |
|---|---|
| HSTS review | Looks for a positive max-age on an HTTPS response. It does not validate your complete HTTPS rollout or certificate setup. |
| CSP missing | Looks for Content-Security-Policy on a declared HTML response. A present policy is not a guarantee that its directives protect your application. |
| Framing review | Looks for frame-ancestors in CSP or a recognized X-Frame-Options value. Whether embedding should be allowed depends on your page. |
| MIME-sniffing review | Checks whether X-Content-Type-Options declares nosniff. It does not verify the actual file contents or every browser's behavior. |
An informational or missing-policy finding is not proof of a vulnerability. Likewise, the presence of a header does not make a policy effective. MDN's CSP documentation also distinguishes enforced policies from Content-Security-Policy-Report-Only, which reports violations without enforcing those restrictions. Seeing the latter does not establish that an enforcing policy is present.
Review policy changes against the application's actual resource and embedding requirements. The checker does not grade security, inspect certificates or validate every directive. For insecure resource references inside HTML, use Mixed Content Checker as a separate source check.
Interpret repeated and hidden header values
The header count refers to distinct normalized names. The occurrence column shows how many times a name appeared, and ordinary repeated values remain visible. More than one occurrence is not automatically an error: decide whether the specific field permits that structure and whether the combined policy is intended.
Sensitive cookie, authentication and recognized secret values are hidden or sanitized. A hidden value is not an absent header, and its presence is not a cookie-security assessment. Do not try to fill redacted values into a shared report. Review confidential details only in an appropriate private debugging environment.
Filter by the name, such as cache-control, rather than expecting the search box to search every value. Keep the report with the tested URL and time when comparing responses. A single header's presence or absence should be interpreted with the final status, resource type and coverage notice.
Distinguish partial checks from HTTP errors
A server returning an error and a checker failing to reach a server are different outcomes. Read the coverage message before interpreting missing rows.
| Result | Meaning and next action |
|---|---|
Final 404 or 500 with headers |
A response was observed. Confirm the URL and investigate the resource or server error; do not mistake connection success for page success. |
| Partial response chain | Some steps were observed, but the final response could not be checked. Final headers are unavailable, not confirmed missing. |
| Timeout or unavailable source | The requested response could not be obtained. Check public access, address and redirect behavior before trying again. |
The checker follows a bounded number of redirects and waits for a limited time. Loops, an inaccessible redirect destination or a response exceeding supported limits can leave the check incomplete. Do not interpret an empty final-header list in that state as a set of missing-security-header findings.
Private network addresses, authenticated pages and requests requiring your browser's cookies are outside this form's scope. An access restriction also does not demonstrate what Googlebot or another genuine visitor receives.
Compare headers after a deployment
Before making a change, record the exact URL, final response, check time and the field you expect to change. Export the report for a baseline. After publishing the intended configuration, check the same URL and compare the relevant values rather than just the number of headers or warnings. Repeat for another resource type when the rule is supposed to apply there too.
If your browser shows something different, open its Network panel, reload the page and inspect the relevant request. Compare the URL after redirects, method and login state. A cached or personalized browser response need not match a public request from another location. This form does not send your user cookies or let you supply custom authentication headers.
Also check whether another diagnostic used HEAD instead of GET. RFC 9110 explains that HEAD has no response content and can omit some fields determined during content generation. Screpy uses GET but stops before downloading the body. Matching the method and request conditions helps you investigate a difference; it does not make every server response identical.