SameSite cookie attribute values and when Lax, Strict or None apply

The SameSite cookie attribute tells the browser whether to send a cookie with requests that come from another site. SameSite=Strict sends it only on same-site requests. SameSite=Lax also sends it when a visitor follows a link to your site, but not on cross-site POST forms, iframes, images or scripts. SameSite=None sends it everywhere, and the cookie must also carry Secure. If a cookie has no SameSite attribute, Chrome treats it as Lax by default, and "cookies without SameSite must be secure" is the name of the old Chrome setting behind the None-requires-Secure rule.

What the SameSite attribute does

Every HTTP cookie can carry a SameSite attribute that tells browsers when to include that cookie in cross-site requests. The attribute was introduced to reduce cross-site request forgery (CSRF) attacks and limit unintended data leakage, but it also affects analytics, embedded content and third-party cookie behaviour.

Three values are available: Strict, Lax and None. Each sets a different level of cross-site sending, as defined in the MDN reference for the Set-Cookie header and the IETF's draft update to the cookie specification (RFC 6265bis).

The attribute sits in the Set-Cookie HTTP response header alongside attributes like Secure, HttpOnly and Path. A typical header looks like this:

Set-Cookie: session_id=abc123; SameSite=Lax; Secure; HttpOnly; Path=/

SameSite Lax vs Strict vs None

Lax and Strict differ in one situation that matters most: a visitor following a link from another site to yours. With Strict, the cookie is not sent on that first request, so a signed-in visitor arriving from an email or a search result looks signed out until they move to a second page. With Lax, the cookie is sent on that top-level navigation, as long as it uses a safe method such as GET. Neither value sends the cookie on cross-site POST forms, iframes, images, scripts or fetch requests. None sends it on all of them.

SameSite=Strict

Cookies marked Strict are only sent when the request comes from the same site. If a visitor clicks a link on an external website that leads to your domain, Strict cookies are not included in that first request. This can cause problems for session cookies: a signed-in user arriving from an email link would appear signed out on the first page load.

Strict suits cookies that should never leave the same-site context: anti-CSRF tokens, internal admin session identifiers and security-sensitive state.

SameSite=Lax

SameSite=Lax means the cookie is sent on same-site requests and on top-level cross-site navigations that use a safe HTTP method, mainly GET. It is not sent on cross-site sub-requests such as images, iframes or POST forms.

That makes Lax suitable for general session cookies. A visitor clicking a link from a search engine or social media post arrives with their session intact, but the cookie is not attached to embedded resources loaded by other sites. Most authentication cookies work well with Lax.

SameSite=None

Setting SameSite=None removes the cross-site restrictions: the cookie is sent with same-site and cross-site requests. It is needed for cookies that really have to work across sites, such as payment provider integrations and embedded widgets that keep state.

Browsers enforce one rule: SameSite=None must be paired with the Secure attribute, so the cookie is only sent over HTTPS. Without Secure, Chromium browsers reject the cookie.

Chrome's SameSite-by-default cookies

If you set a cookie without specifying SameSite, browsers apply their own defaults, and those defaults are not the same everywhere.

Chromium-based browsers (Chrome, Edge, Opera) treat cookies without an explicit SameSite attribute as Lax. According to the Chromium project's SameSite updates page, the change began rolling out with Chrome 80 in February 2020, was paused in April 2020, and resumed with the release of Chrome 84 on 14 July 2020, alongside the rule that SameSite=None requires Secure.

When Lax is applied as a default rather than set by you, Chrome uses a more lenient version: a cookie no more than two minutes old is still sent on a top-level cross-site POST. That temporary exception, which MDN also documents, exists for sign-in flows that post back from another site. Do not rely on it: set the attribute you need explicitly.

Firefox and Safari do not behave the same way. Firefox limits third-party cookies through its Enhanced Tracking Protection. Safari blocks third-party cookies by default through Intelligent Tracking Prevention (ITP), whatever the SameSite value, so even SameSite=None; Secure cookies may be blocked in third-party contexts.

Always set SameSite explicitly on every cookie. Relying on browser defaults produces unpredictable results.

"Cookies without SameSite must be secure" explained

"Cookies without SameSite must be secure" was the name of a Chrome setting, #cookies-without-same-site-must-be-secure, introduced with the 2020 changes. Despite the wording, it applies to cookies with no SameSite restriction, that is SameSite=None: such a cookie must also carry the Secure attribute, or Chrome rejects it.

The Chromium project removed that setting, and #same-site-by-default-cookies, from chrome://flags in Chrome 91 because the behaviour is now on by default. The command-line switch that could still turn it off was removed in Chrome 94. You can no longer switch the rule off in Chrome, so the fix is in your cookies: give every cross-site cookie SameSite=None; Secure and serve the site over HTTPS.

A cookie set as SameSite=None without Secure is dropped without a visible error on the page. The Application panel and the Issues panel in Chrome DevTools show a warning for any cookie rejected for this reason.

How SameSite affects common cookie types

Different kinds of cookies call for different SameSite settings. Getting this wrong can break features or weaken security.

Session cookies like PHPSESSID or framework equivalents usually work best with Lax. This keeps visitors signed in when they arrive through external links while still keeping the cookie out of cross-site sub-requests.

Anti-CSRF tokens should use Strict. Their purpose is to validate same-site requests, so cross-site sending would undermine the protection they provide.

Analytics cookies like _ga are first-party cookies read by JavaScript on your own domain, so they do not need cross-site sending. Google Analytics sets them itself, and you control whether its script loads, not the attributes it writes.

Marketing and advertising cookies that ad networks set in third-party contexts need SameSite=None; Secure to work across domains for conversion tracking and retargeting. These are the cookies most affected by browser restrictions, and they need consent under European privacy law.

The Secure attribute requirement

Chromium browsers reject cookies that set SameSite=None without the Secure attribute, and MDN states that Secure must be set with None. If your site still serves any pages over plain HTTP, cookies with SameSite=None will not work there.

The Secure attribute means the cookie is only sent over encrypted HTTPS connections, which prevents interception in transit. HTTPS should be the baseline for every page, not only checkout or sign-in pages.

SameSite and privacy law

The SameSite attribute is a security mechanism, not a legal exemption. Setting a cookie to Strict does not exempt it from consent requirements under the ePrivacy Directive or the GDPR.

Article 5(3) of the ePrivacy Directive requires prior consent for storing or accessing information on a user's device unless the cookie is strictly necessary for a service the user has explicitly requested. That applies whatever the SameSite value. A Strict analytics cookie still needs consent, and a None payment cookie that is strictly necessary may not.

Where SameSite matters for data protection is the attack surface. Cookies with SameSite=Strict or Lax are harder to abuse in cross-site attacks, which supports the data protection by design principle in Article 25 of the GDPR.

Whatever the attribute, non-essential cookies must be blocked until consent is given. A consent management platform does this by stopping cookie-setting scripts from running before a visitor makes a choice.

Setting SameSite in your code

Set SameSite explicitly on every cookie your application creates. In most frameworks the attribute is one option:

// PHP
setcookie('name', 'value', ['samesite' => 'Lax', 'secure' => true]);

// Express.js
res.cookie('name', 'value', { sameSite: 'lax', secure: true });

# Django settings.py
SESSION_COOKIE_SAMESITE = 'Lax'

Third-party scripts set their own cookies with their own SameSite values, and you cannot override those from your server. The control you have is whether those scripts load at all, which is where conditional script loading based on consent comes in.

Test your cookie configuration in several browsers. Chrome DevTools flags cookies with missing or incorrect SameSite attributes in the Issues panel, and Firefox's Storage Inspector and Safari's Web Inspector show the attributes of each cookie.

Consider the Partitioned attribute for embedded widgets. Cookies Having Independent Partitioned State (CHIPS) lets a cookie set with SameSite=None; Secure; Partitioned be stored in a separate cookie jar for each top-level site. As of October 2026, MDN marks it Baseline 2025, working in the latest versions of the major browsers since December 2025. It is optional: Chrome still allows unpartitioned third-party cookies for people who have not blocked them.

Short answers on SameSite

Check the cookies your pages set

If you are not sure which cookies your site sets, a scan lists each one with its domain, expiry and category, so you can check their attributes and decide which need consent before they load.

Scan your website