Set-Cookie Attribute Analyzer

Paste one Set-Cookie field per line, optionally including the Set-Cookie: prefix. Findings describe syntax and attribute relationships; they are not a security rating or a test of a deployed site, and nothing is sent anywhere. Two kinds of note are kept apart. Producer notes come from the Set-Cookie grammar servers must follow (cookie-name token, flag attributes without values, IMF-fixdate Expires, exactly spelled __Secure- / __Host- / __Http- / __Host-Http- prefixes). User-agent notes follow the parsing and storage algorithms of draft-ietf-httpbis-rfc6265bis-22 (RFC Editor queue, snapshot verified 2026-09-18): the attribute list shows the last raw value of each attribute, while the relationship findings use the attributes a user agent accepts, where an invalid or over-long (1024 octets) occurrence is ignored, the last accepted occurrence wins, and Secure / HttpOnly / Partitioned take effect even when given a value. The user-agent line states whether one of the offline-checkable steps ignores the cookie outright: a CTL other than HTAB anywhere in the string, more than 4096 octets of name plus value, an empty name and value, a non-ASCII Domain, SameSite=None or Partitioned without Secure, or a prefix requirement. User agents match the prefixes case-insensitively (__secure-x and __SECURE-x get the __Secure- rules while remaining distinct cookie names); the __Http- and __Host-Http- rules come from the newer draft-ietf-httpbis-layered-cookies (__Http- is enforced in Chrome 140+, __Host-Http- in Chrome 141+). Steps that need the request (secure connection, domain-match, public suffix, SameSite context) are not evaluated. Because the analyzer has no request URL, a __Host- cookie whose Path is empty or does not start with / is reported as depending on the request's default-path rather than as rejected (the layered-cookies draft rejects it outright); a __Host- cookie with no Path attribute at all is a definite failure. __Host-Http- follows the layered-cookies Host-prefix-compatible rule instead: it requires the retained Path winner to be exactly /; empty or non-/ Path occurrences do not replace an earlier valid winner, and the cookie is a definite failure only when the retained winner is absent or not /. Expires uses the cookie-date algorithm (section 5.1.1, not JavaScript Date parsing) and shows the parsed UTC instant; whether that instant is already past or beyond the 400-day cookie-age-limit is judged against this browser's clock at analysis time. Max-Age is converted exactly, so a very long accepted value is shown as written and as limited to 34560000 seconds (400 days), never as Infinity; zero or negative values expire the cookie at once. The pasted text is a JavaScript string, not wire bytes: octet counts assume UTF-8 and non-ASCII input is flagged. Partitioned follows the Privacy CG CHIPS explainer (Secure required); it is not part of either IETF draft. Cookie values stay opaque.