Questions
Why is my cookie not being set?
When a server sends a cookie and the browser does not store it, the browser has rejected it — silently, as far as the page is concerned. The usual reasons are an attribute combination the browser refuses: a Secure cookie set over plain HTTP, SameSite=None without Secure, a Domain attribute the current host is not allowed to set. The other large family is cross-origin requests, where the cookie is sent but the request was not made with credentials, so the browser never considers storing it.
First, see the reason instead of guessing
Open the network panel of the browser's developer tools and select the response that sets the cookie.
Browsers flag a rejected Set-Cookie header on that response and usually state the reason in a tooltip or a warning.
The application or storage panel shows which cookies were actually stored, which settles whether the problem is setting or sending.
A cookie stored and then not sent back is a different problem — usually path, domain or SameSite — from a cookie never stored.
Checking in a second browser helps, since rules and defaults differ slightly between engines.
Attribute combinations browsers reject
Secure on a response delivered over plain HTTP: the cookie is discarded, except on localhost in some browsers.
SameSite=None without Secure: modern browsers reject the cookie entirely.
A Domain attribute naming a domain the current host does not belong to, or a public suffix — a host cannot set cookies for a sibling or a parent it does not share.
A cookie name with the __Host- prefix that includes a Domain attribute, lacks Secure, or has a Path other than the root.
A cookie larger than the browser's limit, around four kilobytes for name and value together, which is dropped.
Cross-origin requests
A request from a page on one origin to an API on another only stores cookies if it was made with credentials — the fetch or XMLHttpRequest option has to ask for them.
The response must then also allow credentials explicitly, and name the requesting origin rather than using a wildcard.
If either side is missing, the browser ignores the Set-Cookie header on that response.
The cookie must also carry SameSite=None and Secure to be usable in a cross-site context at all.
This is why a login that works when the API and the page share an origin fails when they are split.
Third-party cookie restrictions
When the cookie belongs to a site other than the one in the address bar, many browsers block it by default or partition it.
An embedded widget, an iframe login or an API on a different registrable domain all fall into this category.
No attribute combination guarantees such a cookie is stored in every browser.
The durable fix is to serve the endpoint from a subdomain of the site, which makes the cookie first-party.
When the cookie is set and then disappears
A Path attribute narrower than the pages that need it means the cookie is not sent to those pages.
A cookie without an expiry is a session cookie and disappears when the browser session ends.
Setting the same name with different Domain or Path attributes creates two cookies, and the wrong one may be sent first.
A CDN or cache that strips Set-Cookie headers from cached responses means some visitors never receive the cookie.
Clearing a cookie requires matching the original Domain and Path exactly, which is why logout sometimes appears not to work.
What an external scan reports
The cookies the site sets on anonymous responses, with their attributes as sent.
Missing Secure flags and SameSite=None without Secure, which are exactly the combinations browsers reject.
Domain and Path scoping, and cookie size.
Whether an API's cross-origin response allows credentials, and whether it does so with a wildcard.
What it cannot see is a cookie set only after login, or the rejection reason a particular browser gave.
Frequently asked questions
- The Set-Cookie header is in the response. Why is nothing stored?
- The browser rejected it. The network panel usually flags the header and states the reason — commonly Secure over HTTP, or SameSite=None without Secure.
- Why does my login work locally but not in production?
- Often because production splits the page and the API across origins. The request then needs credentials, the response must allow them for the named origin, and the cookie needs SameSite=None with Secure.
- Can I set a cookie for a different domain?
- No. A host can set cookies for itself and for its parent domain, but not for an unrelated or sibling domain, and never for a public suffix.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website