HTTP response header analyzer

Developer tools

Loading tool

The tool is loaded only when you open it.

All processing for this tool happens in your browser. Your input is not sent to a server.

About this tool

Paste response headers from developer tools or a command-line capture to inspect them in your browser. An optional status line identifies the response; repeated headers remain separate, including Set-Cookie values containing date commas. Select a response block to review caching, content type, Location, CORS and context-dependent security advice. The analyzer makes no requests, stores no input history and sends no header telemetry. It displays values as plain text without executing HTML. Copied or exported details can still contain secrets: this is not a redaction tool.

Common uses

Compare cache directives on a captured API or asset response before checking the browser or CDN configuration.
Inspect repeated headers and select individual responses from a pasted redirect or informational-response sequence.
Review declared MIME type, charset, redirect location and CORS headers while keeping unknown request context explicit.

How to use it

1.Paste only response headers, optionally beginning with a status line such as HTTP/1.1 200 OK. Separate responses with a blank line and begin every later block with a status line. Keep the input within 256 KiB of UTF-8 text, 4,000 lines and 32 blocks.
2.Analyze the input, correct any error at the reported line and column, then select the response block to inspect. Set the transport context to HTTPS or HTTP only if you know it; otherwise leave it unknown.
3.Read the preserved fields and grouped findings together with the original request. Copy or download the selected block’s JSON report only after checking every included value for cookies, tokens, identifying URLs and other sensitive information.

Synthetic response-header examples

Two cookies with a comma inside an expiry date

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Content-Type-Options: nosniff
Set-Cookie: session=demo-session; Expires=Wed, 21 Oct 2026 07:28:00 GMT; Secure; HttpOnly
Set-Cookie: theme=dark; Path=/; SameSite=Lax

One response block · two separate Set-Cookie fields
Declared MIME type: text/html · charset: utf-8
X-Content-Type-Options: nosniff

The date comma stays inside the first cookie value. nosniff asks browsers to honor the declared MIME type; the analyzer does not load a body or verify that it is HTML. Both synthetic cookie values remain visible and are not redacted from output.

Choose between a redirect and a later response

HTTP/1.1 301 Moved Permanently
Location: /docs
Cache-Control: max-age=300

HTTP/2 200
Content-Type: application/json
Cache-Control: no-cache
ETag: "demo-v2"

Two response blocks: 301, then 200
First block: Location /docs · max-age=300
Second block: application/json · no-cache · ETag "demo-v2"

Select each block separately. The relative Location needs the original request URL to resolve, and is never opened here. The second response requires validation before cache reuse; no-cache does not itself forbid storage. The tool does not infer that these two blocks belong to a verified redirect chain.

Review contradictory storage instructions

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Cache-Control: public, private, max-age=600, no-store

Review public and private together
no-store prohibits storage despite max-age=600

These deliberately conflicting directives are a configuration review case. A freshness lifetime does not override no-store. Inspect the server and intermediary settings that produced the response rather than assuming a cache will retain it for ten minutes.

CORS headers without a status line

Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

One response block · status unknown
Wildcard origin with credentials allowance needs review
Actual CORS outcome: unknown

The first block may omit its status line. This pair cannot authorize a credentialed CORS response, but the pasted headers do not reveal whether credentials were used or whether cross-origin access was needed.

Common header-analysis mistakes

Pasting a full response body, a curl command or a request line: copy only response-header sections, with optional supported status-line notation.
Leaving out the colon or adding whitespace to a field name: use Name: value and fix the reported line and column. Old multiline folded headers are rejected.
Separating bare header groups with blank lines: only the first block may omit its status; every later block must begin with a new status line.
Treating HTTP/2 as proof of HTTPS, a missing security header as proof of a vulnerability, or a CORS warning as a confirmed failed request: verify the missing context.
Confusing no-cache with no-store, or reading max-age as guaranteed browser or CDN retention: inspect all applicable directives and the request.
Sharing a report as if export had sanitized it: review raw cookies, tokens, Location query strings and custom header values yourself.

Limits and notes

Input is limited to 256 KiB (262,144 UTF-8 bytes), 4,000 lines and 32 response blocks. A rejected input produces no partial analysis; smaller, complete header sections are easier to inspect.
This is a text parser, not a network client or wire-protocol validator. It accepts HTTP/1.0, HTTP/1.1, HTTP/2 and HTTP/3 status-line notation from text captures. Request lines, response bodies, HTTP/2 pseudo-headers and obsolete folded continuation lines are unsupported.
Response headers alone cannot establish actual cache reuse, CORS success, redirect destinations relative to an unknown request URL, or whether a declared MIME type and charset match the body. The analyzer never follows Location or tests an endpoint.
Security findings are conditional checks, not a grade or proof of a vulnerability. HSTS advice depends on the original transport; HTTPS cannot be inferred from HTTP/2 or HTTP/3 notation. Header presence alone does not validate a policy, TLS configuration or an application.
Copy and download include the selected response block and its findings, not the other blocks. Raw values remain: export does not remove credentials, Set-Cookie values, internal hostnames or identifiers. Local processing and plain-text display do not make the result safe to share; downloaded files persist on your device.

Frequently asked questions

Does no-cache mean that a response cannot be stored?

No. Unqualified no-cache requires successful validation before a stored response is reused; no-store normally prohibits storage, with a specified exception for caches that understand and implement must-understand. max-age sets a freshness lifetime in seconds, while s-maxage overrides it for shared caches. Unqualified private disallows shared storage; public permits shared caching under applicable rules. Other directives and request context still matter, and conflicting values deserve review.

Can these headers prove that a cross-origin request will work?

No. The request Origin, credentials mode, method, request headers and any preflight exchange also matter. Access-Control-Allow-Origin: * cannot authorize a credentialed CORS response, even with Access-Control-Allow-Credentials: true. Missing CORS headers are not automatically a problem for a resource that is not intended for cross-origin script access.

Why must I choose the HTTP or HTTPS context myself?

A pasted status line does not identify the original URL scheme. Browsers ignore Strict-Transport-Security received over HTTP; HSTS is established over HTTPS. A missing header in one capture does not reveal any previously stored HSTS policy. Choose only the context you can verify and treat the findings as prompts for further checks.

Why preserve duplicate headers instead of merging them?

Different fields have different combination rules. Set-Cookie lines must remain separate, and an Expires date contains a comma that must not split the cookie. The analyzer preserves original field order and values for review; this also preserves any secrets. Copying or exporting does not sanitize them.