Cookie String Decoder
Paste raw Set-Cookie headers and get a complete
plain-English breakdown of every attribute. Missing security flags are highlighted,
tracking-style cookies are flagged, and SameSite / expiry issues are explained.
You can also inspect the cookies set by this very page.
| Attribute | Effect | Missing = Risk? |
|---|---|---|
| HttpOnly | Blocks JavaScript access — prevents XSS theft | High |
| Secure | Sent only over HTTPS — prevents interception | High |
| SameSite=Strict | Never sent on cross-site requests — strongest CSRF protection | Medium |
| SameSite=Lax | Sent on safe cross-site navigation only | Low |
| SameSite=None | Sent on all cross-site requests — requires Secure | High |
| Max-Age / Expires | Controls when the cookie is deleted | Low |
| Domain | Subdomains that receive the cookie | Low |
| Path | URL prefix that triggers cookie sending | Low |
| Partitioned | CHIPS — isolates cookie per top-level site | Low |
Frequently Asked Questions
What is a Set-Cookie header?
The Set-Cookie header instructs the browser to store a cookie, including its name, value, and optional attributes: Expires, Domain, Path, Secure, HttpOnly, and SameSite.
What does HttpOnly mean?
HttpOnly cookies cannot be accessed by JavaScript. This prevents XSS attacks from stealing session cookies and should always be set on authentication cookies.
What does the SameSite attribute do?
SameSite controls cross-site request behaviour. Strict blocks all cross-site sending. Lax allows GET requests. None allows all cross-site requests but requires the Secure flag.
Is my cookie data sent anywhere?
No. All cookie parsing runs locally in your browser using JavaScript. Your cookie strings are never transmitted to any server.