Skip to content
MtrXTools

Cookie inspector

Inspect every Set-Cookie a site sends across its redirects, or pasted Set-Cookie headers: Secure, HttpOnly, SameSite, the __Host- and __Secure- prefixes, Partitioned, Domain, lifetime and size, including mistakes that make browsers silently drop a cookie.

What it checks

  • Every Set-Cookie header on the way to the page, including the ones sent on redirects, with the response that set each one.
  • Rules that make browsers refuse a cookie without any error: SameSite=None or Partitioned without Secure, a Secure cookie set over plain HTTP, the __Host- prefix (needs Secure, Path=/ and no Domain) and the __Secure- prefix (needs Secure), a Domain that doesn't cover the host or is a whole top-level domain, characters not allowed in a name, and cookies over 4 KB.
  • Weaknesses: cookies without Secure, session or login cookies scripts can read (no HttpOnly), missing or None SameSite, lifetimes past Chrome's 400-day cap, long-lived logins, and a Domain that shares the cookie with every subdomain.
  • Well-known cookies by name (Google Analytics, Meta pixel, Cloudflare, load balancers, framework sessions and CSRF tokens), with a note when analytics or advertising cookies are set before the visitor has agreed to anything.

Enter a URL to see what the server sets, or paste Set-Cookie headers (one per line) to check them before you deploy. Cookies set later by scripts on the page aren't visible here; the browser's developer tools show those under Application, Cookies.

A safe session cookie

For a login or session cookie, Set-Cookie: __Host-session=…; Path=/; Secure; HttpOnly; SameSite=Lax covers the basics. Secure keeps it off plain HTTP, HttpOnly keeps it away from scripts (so a cross-site scripting bug can't steal it), SameSite=Lax stops it being sent on most cross-site requests, and the __Host- prefix makes the browser enforce all of that and stops subdomains overwriting it.

Leave out Max-Age and Expires to end the cookie when the browser closes, or keep the lifetime short and renew it while the visitor is active. Use SameSite=None only for cookies an embed or third-party widget needs, always with Secure, and add Partitioned so it keeps working in browsers that block third-party cookies, such as Safari and Firefox.

Questions

Why did my cookie disappear?
Browsers drop cookies that break a rule and report nothing to the server. The usual causes are SameSite=None without Secure, a Secure cookie set over http://, a __Host- cookie with a Domain or a Path other than /, or a Domain that doesn't match the site. The browser's developer tools show the reason on the response's cookie tab.
What does SameSite do?
It controls whether the cookie is sent when another site links to, embeds or submits a form to yours. Strict never sends it cross-site, Lax sends it only when the visitor follows a link to you, and None always sends it. Lax is a good default; Chrome and Edge already treat cookies without SameSite as Lax, Safari and Firefox don't.
Should every cookie be HttpOnly?
Every cookie only the server reads should be, above all sessions and login tokens. Cookies your page's scripts read, such as a CSRF token sent back in a header or a theme preference, can't be HttpOnly, and that is fine.
Does this tool see consent banner cookies?
It sees only cookies set by the server in Set-Cookie headers, as a first-time visitor who hasn't clicked anything. Cookies set by scripts, including most analytics tags and consent tools, appear in the browser's developer tools instead.

Related tools