Toolvore

HTTP Header Inspector & Compare

Inspect and compare pasted HTTP response headers locally, keeping repeated fields and response blocks.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Inspect and compare pasted HTTP response headers locally, retaining repeated fields and explaining cache and security context without claiming a live site audit.

How to use it

  1. 1Paste response headers in A and an optional second sample in B.
  2. 2Inspect, select response blocks, and review repeated fields or ignored lines.
  3. 3Compare exact values and export parsed fields or the comparison as JSON/CSV.

Example

Input
A: Cache-Control: public, max-age=300 B: Cache-Control: private, no-cache
Output
cache-control: Changed; public freshness directive compared with private revalidation directive

This compares pasted text; actual cache behavior depends on additional context.

What happens to your data

Header text stays in page memory and no URL is fetched. It is not stored in the browser or URL. Explicit exports can contain the cookie values or other sensitive fields you pasted.

Last updated October 2026

Inspect and compare pasted HTTP response headers without making a network request. Paste one response into A or add a second response in B to see which field names are unchanged, changed or present on only one side. Repeated fields remain separate and ordered, so two Set-Cookie fields do not collapse into a single value. The selected blocks also receive plain-language cache and security-header explanations.

This is a local text inspector, not a live URL checker or a site audit. The pasted text cannot establish which connection produced it, whether a browser accepted a policy, or what a CDN actually served. Use the original response capture and application context alongside the notes. Copy JSON or download the supplied fields and comparison for a review.

How it works

Copy response headers from browser developer tools or a command such as curl -I, then paste the text into Response A. Response B is optional. A status line is useful but not required: ordinary name: value lines can be inspected on their own. The parser accepts textual HTTP/1.0, HTTP/1.1, HTTP/2 and HTTP/3 status lines, plus :status: values copied from HTTP/2 tooling. A leading curl response marker consisting of a less-than sign and space is removed.

A new status line starts a new block, and a blank line separates blocks of fields. This accommodates multiple responses copied from a command output. The final supplied block is selected initially; if more than one block exists, choose the specific response to inspect or compare. The sequence is only a sequence of supplied text. The tool does not verify that those blocks came from a redirect chain, the same origin, or even the same request.

Each side accepts at most 65,536 characters, 1,000 lines, 500 fields and 20 response blocks. Invalid field-shaped lines and obsolete folded continuation lines are reported with their line numbers. Control characters reject the input. Paste headers only: response bodies, request lines, curl diagnostic prose and arbitrary JSON are outside the supported format. A body line that happens to look exactly like a header cannot be distinguished from one by this text-only parser.

Field names compare without regard to letter case. Values compare exactly after trimming surrounding spaces and tabs, and repeated values retain their original order. A difference therefore means a difference in the supplied text, not necessarily a change in HTTP behavior. Two equivalent policies written differently may be marked Changed, while an unchanged policy may behave differently on another origin, request or response. The status lines remain visible separately from the per-field comparison.

The parser never splits Set-Cookie values at commas. An Expires attribute commonly contains a comma inside a single cookie field, while two Set-Cookie lines represent two separate fields. The JSON and field CSV exports retain that distinction. Repetition is not automatically declared valid for every header; some fields support lists and others have specific rules. A repeated-field note helps you identify where a closer protocol review is useful.

Cache explanations distinguish storage from reuse. For example, no-cache commonly permits storing a response but requires validation before reuse, whereas no-store instructs a cache not to store it. An unqualified private directive excludes shared caches, and s-maxage describes shared-cache freshness. These are explanations of supplied directives, not a cache simulator. Request headers, response age, validators, other response fields and intermediary rules can change what actually happens.

Security notes describe a field's purpose and limitations without assigning a score. An enforcing Content-Security-Policy field still needs a directive-level and page-level review; a report-only policy does not enforce restrictions. Strict-Transport-Security depends on a valid HTTPS connection, and an existing or preloaded browser policy may exist even if no field appears in the sample. Missing from this pasted block is not the same as missing everywhere on the site.

Editing either side clears previous results, so exports cannot accidentally refer to an older input. The tool keeps text only in page memory and does not put it in the URL or browser storage. Downloads are an explicit local action. CSV prefixes potentially formula-like cells with an apostrophe; JSON preserves the parsed values without that spreadsheet-specific change. Cookie values and other sensitive fields remain visible in exports, so review the actual report before sharing it.

Worked example: compare caching while preserving separate cookies

Input
Load comparison example: A contains public, max-age=300 and two Set-Cookie fields; B contains private, no-cache, CSP and HSTS.
Result
4 field names differ; Content-Type, Vary and X-Content-Type-Options are unchanged. A retains both Set-Cookie fields, including the comma in Expires.

The example illustrates a textual comparison. It does not claim either sample is a complete or recommended site configuration.

Common use cases

  • Comparing headers captured before and after a configuration change
  • Checking that repeated Set-Cookie fields survived a copied response
  • Explaining cache directives during a support investigation
  • Reviewing multiple pasted response blocks without contacting their origins

Frequently asked questions

Can I enter a website URL to fetch its headers?+

No. This interface inspects pasted response text locally. Capture headers with your browser's network panel or a suitable HTTP client, then paste the output. The tool does not contact the website.

Is no-cache the same as no-store?+

No. no-cache generally requires successful validation before reuse of a stored response; no-store instructs caches not to store it. Other directives and request context still matter. The notes explain the text without measuring a live cache.

Does a missing security header mean my site is unsafe?+

This sample alone cannot answer that. It may be incomplete or belong to a particular resource, and some policies can already be known to a browser. Review the application, transport and actual enforced policy; the inspector does not produce an audit verdict.

Are duplicate headers lost during comparison?+

No. Every parsed field keeps its own value and source line. Repeated values are compared as ordered arrays, and Set-Cookie is never split at commas. JSON and CSV retain the separate rows.

Why does the comparison show a change for equivalent values?+

The comparison checks text rather than implementing every header's grammar. Differences in value case, formatting or repeated-value order can be semantically equivalent yet appear Changed. Use the result to locate differences, then interpret them in context.