Inspect raw Set-Cookie response headers, surface effective attributes, and flag browser policy issues such as SameSite=None without Secure.
Parse raw Set-Cookie lines, expose effective attributes, and flag browser behaviors that commonly break auth and session flows.
When `Path` is omitted, the browser derives a default path from the request URL that set the cookie. That behavior is easy to overlook and can make a cookie available in fewer routes than your team expects. An explicit `Path=/` or another intentional scope is usually clearer and easier to debug.
SameSite controls whether the browser sends the cookie with cross-site requests. `Strict` blocks all cross-site sends, including top-level navigations like links from external sites. `Lax` allows cookies on safe top-level navigations but not on POST or embedded fetches — the modern browser default. `None` allows cross-site sends but requires `Secure`. Use `Lax` for most session cookies and `None; Secure` only when third-party contexts are explicitly required.
A Set-Cookie inspector helps you reason about what a browser will actually do with a response header, not just what the backend intended to send. Cookie bugs are often caused by one missing attribute, a confusing default path, or a cross-site policy mismatch that only appears after deployment.
By parsing each `Set-Cookie` line into a clean attribute view and attaching focused warnings, the tool makes auth and session debugging much faster during frontend-backend handoff, incident review, and local environment setup.
Paste one or more raw `Set-Cookie` header lines exactly as they appear in logs or browser devtools. The inspector splits the cookie name and value from its attributes, shows the effective flags, and warns about patterns such as `SameSite=None` without `Secure`, missing `Path`, or sensitive-looking cookies that are not `HttpOnly`.
Example:
Input: `refresh_token=def456; Path=/auth; HttpOnly; SameSite=None`
The inspector highlights that `SameSite=None` is present but `Secure` is missing. In modern browsers, that usually prevents the cookie from being accepted in cross-site contexts, which can look like a random login failure if you only inspect the backend response superficially.1. Debugging why a login cookie is set in the response but absent in the browser store.
2. Reviewing auth cookie changes before shipping a new session strategy.
3. Comparing staging and production response headers during cross-site redirect flows.
4. Teaching teammates the practical effect of `Path`, `SameSite`, `Secure`, and `HttpOnly`.
Modern browsers reject cross-site cookies that declare `SameSite=None` without also declaring `Secure`. The pair is treated as a safety boundary, so omitting `Secure` often makes the cookie silently fail in real auth flows.
No. It is a pure parser and attribute auditor for raw header text. That keeps the inspection local and lets you paste sensitive staging headers without sending them anywhere.
No single parser can guarantee that because browser context still matters, including HTTPS, third-party framing, redirects, and storage policies. The tool focuses on the high-signal header mistakes that cause a large share of real cookie bugs.