Session cookie is set, but the next request is signed out.

Start at the response that sets it.

Open the browser’s Network and storage panels. Check the Set-Cookie response and any blocked-cookie explanation. Then check whether the cookie is stored under the hostname you expected.

The Set-Cookie parser helps read copied attributes, including an Expires date with a comma. It cannot tell you whether your browser accepted the cookie. Redact the value before sharing screenshots.

Compare the destination with the cookie scope.

A stored cookie can still be absent from the request because of its host, Path, Secure, SameSite or expiry. HttpOnly prevents JavaScript from reading a cookie; it does not prevent the browser from sending it to an eligible request.

Do not widen Domain or remove Secure just to make a test pass. Determine the intended host and request context first. For cross-origin fetches, check the credentials setting as well as CORS.

// This is a server response header, not browser JavaScript:
Set-Cookie: session=REDACTED; Path=/; HttpOnly; Secure; SameSite=Lax

This illustrates common first-party attributes, not a universal setting for embedded or cross-site authentication.

Look for competing cookies.

Two cookies with the same name can exist at different paths or domains. Inspect the complete outgoing Cookie header and the server’s parsing behaviour. When deleting or replacing a cookie, use the matching scope.

Also check the server-side session record. A cookie being present does not prove that the session exists, has not expired or is accepted by the current environment.

Reproduce the whole return journey.

Start signed out. Sign in, follow the redirect, inspect the first authenticated request and reload. Repeat with an expired cookie and the browser modes your users actually use. Keep anti-CSRF protections and server authorisation in place.

Reference: MDN’s Set-Cookie reference. A minimal local cookie-attribute parser is not an authentication audit.