I set SameSite=None and Secure. Why do some users still have no cookie?

Because that makes it a third-party cookie in a cross-site context. Safari blocks those by default, Firefox partitions them per top-level site, and Chrome has been phasing them out. The header can be exactly right and still fail for a large share of real traffic — which is the argument for moving the flow same-site rather than fixing the attributes.

Why can''t I see the cookie in document.cookie?

HttpOnly. It hides the cookie from JavaScript but does not stop the browser storing or sending it — that is the point of the flag. Check the Application tab in DevTools instead, or the request headers.

SameSite Cookie Checker — Why Isn't My Cookie Sent?

chain

◉

Set-Cookie Checker — why isn't my cookie sent? nothing uploaded

SET-COOKIE HEADER

THE REQUEST YOU CARE ABOUT

URL THAT SET THE COOKIE

Computed in this tab from the RFC 6265bis rules — nothing is sent anywhere. The value is shown truncated, and a cookie that looks like a session token is kept out of your tool history automatically.

Set-Cookie Checker Online

Updated 2026-08-05

// how to use

1 Paste the Set-Cookie header from your response (the whole header block is fine).
2 Pick the request you actually care about — a cross-site fetch behaves nothing like a link click.
3 Read both verdicts. A cookie can be stored perfectly and still be withheld.

// examples

No SameSite at all

Input

Set-Cookie: sessionid=abc; Path=/; Secure  ·  cross-site fetch

Output

Stored, but NOT sent — browsers default a missing SameSite to Lax.

SameSite=None without Secure

Input

Set-Cookie: id=abc; SameSite=None

Output

Not stored at all — None requires Secure, so the cookie never exists.

A __Host- cookie with a Domain

Input

Set-Cookie: __Host-id=abc; Secure; Path=/; Domain=example.com

Output

Not stored — __Host- forbids Domain, and the browser rejects it silently.

// common uses

Working out why a login cookie is not coming back on an API call Checking a SameSite change before you deploy it Understanding why a cookie disappears in Safari but not Chrome Debugging a __Host- or __Secure- prefixed cookie that vanishes without an error

// faq

Why does it work in curl and Postman but not in the browser?

Because curl and Postman have no SameSite, no first-party context and no cookie prefixes. They prove the server sent the right header; they say nothing about whether a browser will keep it or return it. Almost every report of this shape comes down to the SameSite default.

I did not set SameSite at all. Isn''t that "no restriction"?

It used to be. Since 2020 browsers treat a missing SameSite as Lax, which withholds the cookie on cross-site fetches, iframes and subresources. A missing attribute is now a restrictive one, and that change is why requests that worked for years suddenly stopped.

What is the difference between Lax and Strict?

Lax still sends the cookie when someone navigates to your site by clicking a link — a top-level request with a safe method. Strict withholds it even then, so a user arriving from an external link appears logged out until they navigate again. Strict is safer and more surprising.

// works with your data

CORS Checker CSP Checker HTTP Status Codes URL Parser JWT Decoder

Use this via API

Get a free API key →

curl -X POST https://thesnaptools.com/api/v1/tools/cookie-checker \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"header":"Set-Cookie: sessionid=abc; Path=/; Secure \u00b7 cross-site fetch"}'