Explain cookie scope and cache reuse rules
Cookies rejected or personalized responses cached? Inspect Set-Cookie, Cache-Control, Vary and ETag together.
Cookies rejected or personalized responses cached? Fetch a page or paste headers to explain Set-Cookie, Cache-Control, Vary and ETag. Pasted headers stay local. Jump to: What does it mean?, How to fix it, Break it, Ask your agent.
Example Synthetic response headers combine an insecure prefixed cookie with shared-cache policy.
1 cookie inspected; cache policy explained. SameSite=None requires Secure. 3 more findings to review.
This parses supplied response fields only. Origin, request context, public suffixes and actual browser cookie or cache behavior are not tested.
Pasted headers stay in your browser. They are parsed here and never uploaded.
A website address means one page request from our server. Only the address is sent when you choose Fetch headers; cookie values are redacted before they reach this page.
Findings
Fail SameSite=None requires Secure
__Host-session: modern browsers reject this combination.
Fail __Host- prefix requirements fail
Use Secure, Path=/ and no Domain attribute, from a secure origin.
Check Cookie lacks Secure
__Host-session: the header does not restrict sending to secure transport.
Check Shared caching with Set-Cookie
Set-Cookie alone does not prevent caching. Review whether this response contains personalized data.
Info ETag is a validator, not a lifetime
A matching validator may support conditional requests; it does not independently make a response fresh.
Evidence
Cookies
Value [not displayed, 12 bytes] Attributes Path / Sent with requests under this path HttpOnly true Not readable by script SameSite None Cross-site sending rule Scope Host-only cookie Which hosts receive it Lifetime Session cookie How long browsers keep it Fail SameSite=None requires Secure
__Host-session: modern browsers reject this combination.
Fail __Host- prefix requirements fail
__Host-session: use Secure, Path=/ and no Domain attribute, from a secure origin.
Check Cookie lacks Secure
__Host-session: the header does not restrict sending to secure transport.
| Cache policy | ||
|---|---|---|
| Directives | ||
| public | true | Any cache may store it |
| max-age | 60 | Browsers may reuse for this long |
| s-maxage | 300 | Shared caches may reuse for this long |
| Storage | Storage depends on response status, request headers and other cache rules. | |
| Browser freshness | 60 | Seconds a browser may reuse it |
| Shared-cache freshness | 300 | Seconds a shared cache may reuse it |
| Vary | Accept-Encoding | One stored copy per value of these request headers |
| ETag | "inventory-v1" | Validator for conditional requests, not a lifetime |
Header interpretation
Show the header interpretation
{
"cookies": [
{
"name": "__Host-session",
"value": "[not displayed, 12 bytes]",
"attributes": {
"path": "/",
"httponly": true,
"samesite": "None"
},
"scope": "Host-only cookie",
"lifetime": "Session cookie"
}
],
"cache": {
"directives": {
"public": true,
"max-age": "60",
"s-maxage": "300"
},
"storage": "Storage depends on response status, request headers and other cache rules.",
"browserFreshness": "60",
"sharedFreshness": "300",
"vary": "Accept-Encoding",
"etag": [
"\"inventory-v1\""
]
}
}Take it further
What this result means
Written for the example.
Ask for a review of the findings and a test that verifies the proposed fix. Input values are not included automatically.
Synthetic response headers combine an insecure prefixed cookie with shared-cache policy.
Synthetic response headers combine an insecure prefixed cookie with shared-cache policy.
Check representative input and one deliberate failure. Confirm the result in the application that consumes it.
Read the findings before changing the input. Break it lets you inspect a failure, and Heal it restores the previous input.
This parses supplied response fields only. Origin, request context, public suffixes and actual browser cookie or cache behavior are not tested.
How it works
Cookie Header Explainer reads response headers, from a public page our server fetches or from text you paste, and explains every cookie and the cache policy with the evidence behind each finding. Cookies are checked against the browser rules in RFC 6265bis: prefixes, SameSite, size limits, lifetime and scope; cache directives against RFC 9111. The full method, every finding and worked examples are on docs.tamperbox.dev.
Limits and interpretation
The result reads the supplied fields only. The page origin, the request, public suffix rules and what a real browser or cache finally stores are not tested. Cookie values are never displayed: fetched values are redacted by our server, pasted values stay in your browser and only their length is shown. Inputs are limited to 1,000,000 characters. Nothing is fetched from addresses inside pasted text.
Frequently asked questions
Is my input uploaded?
Pasted headers are not. They are parsed in your browser. A website address is different: our server requests that one page and returns its response headers with cookie values redacted.
What does the opening result show?
The response headers www.wikipedia.org sent when the page opened, fetched live by our server. The site can change its cookies at any time. If the fetch fails, a synthetic header block is shown instead and labelled Example.
Does a clean result mean my cookies work?
No. It means the headers follow the rules this page checks. Confirm in the browser's storage panel that each cookie is stored, and in your cache that personalized responses are not reused.
References
Are you an AI agent? You are in the right place.
Read this tool as plain text with its methods and limits. Use the website interface; no dedicated MCP operation is available.