In February 2020, Chrome 80 changed one default and broke a lot of cross-site logins overnight. Any cookie that didn't declare a SameSite value started behaving as SameSite=Lax, which meant it stopped being sent on most cross-site requests. If you've ever wondered why an embedded widget lost its session or a third-party tracker suddenly went quiet, this attribute is usually why.
SameSite is a single cookie attribute that controls one thing: whether the browser attaches a cookie to requests that come from a different site. Get it wrong and you either leak a cookie into contexts it shouldn't reach, or you break functionality that depends on it. Get it right and you close off a whole class of cross-site request forgery.
"Same-site" is not "same-origin"
The two terms look alike and mean different things. Same-origin means the scheme, host, and port all match exactly. Same-site is looser: it compares the registrable domain, the part you actually register with a registrar (roughly the "eTLD+1", like example.com).
So app.example.com and checkout.example.com are same-site with each other, even though they're different origins. But example.com and widget.io are cross-site. When a page on one site makes a request to another site (loading an iframe, an image, a script, a background fetch), that's a cross-site request, and SameSite decides whether your cookie goes along for the ride.
Modern Chrome also folds in the scheme, a refinement called "schemeful same-site". Under that rule, http://example.com and https://example.com count as cross-site. One more reason to serve everything over HTTPS.
The three values
Strict. The cookie is sent only on requests that start from its own site. Follow a link from an external page into your site and the browser withholds the cookie on that first request, even though you're arriving at the cookie's own domain. That's ideal for a "delete account" action you never want triggered from another origin, and awkward for a session cookie, because a user arriving from a search result would look logged out until they click again.
Lax. A middle ground. The cookie is withheld on most cross-site requests (an iframe, a background fetch, an image beacon), but it is sent when the user performs a top-level navigation with a safe method, like clicking a normal link (a GET). This is why Lax works for login sessions: arrive from an external link and you're still signed in, but a hidden cross-site request can't quietly carry your cookie.
None. The cookie is sent on every request, cross-site included. This is the only value that keeps a cookie working in a genuine third-party context, and browsers now require it to be paired with the Secure attribute. A SameSite=None cookie without Secure is rejected outright.
SameSite values at a glance
| Behavior | Strict | Lax | None |
|---|---|---|---|
| Sent on same-site requests | Yes | Yes | Yes |
| Sent when arriving via a link from another site | No | Yes | Yes |
| Sent on cross-site iframe, image, or fetch | No | No | Yes |
| Must also set Secure | No | No | Yes |
| Good for | Sensitive actions | Login sessions | Cross-site embeds, tracking |
Why the default flipped in 2020
Before Chrome 80, a cookie with no SameSite attribute was sent on every request, same-site or not. That made cross-site request forgery easy and handed third-party trackers a free ride. Chrome, followed by Firefox and the rest, changed the default so an unspecified cookie is treated as Lax.
There's a wrinkle worth knowing. When Lax is applied as the browser's default (rather than set explicitly), Chrome uses a slightly more permissive version: a freshly set cookie is also sent on a top-level cross-site POST for the first two minutes after it's created. Set SameSite=Lax yourself and you don't get that two-minute grace. The practical lesson is to always declare the attribute rather than lean on the default.
SameSite=None means nothing without Secure
Since the 2020 rollout, a cookie sent as SameSite=None must carry the Secure attribute, so it only travels over HTTPS. Browsers drop a None cookie that lacks Secure. If a third-party integration stopped working after 2020, an un-upgraded SameSite=None cookie on a plain HTTP endpoint is the classic cause.
What SameSite means for consent
SameSite is a security control, not a consent mechanism. A SameSite=Strict cookie can still be a tracking cookie, and it still needs consent under the GDPR and the ePrivacy rules if it isn't strictly necessary. The attribute limits where a cookie is sent; it says nothing about why you set it or whether you asked permission.
The overlap runs in one direction. A cross-site tracking cookie now needs SameSite=None; Secure to function at all, which makes it easy to spot. A cookie declared SameSite=None is announcing that it's built to work in a third-party context. When CookieBeam scans a site, it records each cookie's attributes next to its category, so a None cookie firing before consent stands out in the inventory. And because CookieBeam holds tagged scripts until the visitor opts in, the cookies those scripts would set, whatever their SameSite value, never reach the browser on a reject.
How to check what you've got
Open your browser's developer tools, go to the Application panel (Chrome) or Storage panel (Firefox), and look at the Cookies list. Every cookie shows its SameSite, Secure, and HttpOnly columns. A blank in the SameSite column means the browser is applying its default. Two mistakes turn up constantly:
- Session cookies left unset. Relying on the Lax default usually works, but the two-minute POST quirk and inconsistent behavior on older clients make an explicit value safer. Set
SameSite=Laxon session cookies deliberately. NonewithoutSecure. The cookie is silently rejected. The browser console logs the rejection if you look.
For how long those cookies then live, see session vs persistent cookies. For the Secure and HttpOnly flags SameSite sits beside, see Secure and HttpOnly cookie flags, and for how the browser scopes a cookie by host, see cookie Domain and Path.