SameSite Cookies Explained for Beginners: A Simple Visual Guide

Last updated: 2026/02/07

The SameSite attribute sounds technical, but the idea behind it is actually simple.
It controls when a browser is allowed to send your cookies.

Modern browsers like Chrome changed their default behavior, which is why cookies are no longer sent automatically across different websites.

This guide uses simple visual explanations to help beginners understand the difference between
SameSite=Lax, Strict, and None.

What Is the SameSite Attribute?

SameSite decides under what conditions a cookie will be sent.

Before SameSite became strict, cookies were sent everywhere — even when loading images or iframes from another domain.
That made cross-site tracking extremely easy.

SameSite fixes this by giving browsers clear rules.

Visual Guide: The 3 SameSite Modes

::contentReference[oaicite:0]{index=0}

SameSite has only three values:

• Strict — most restrictive
• Lax — the modern default
• None — for third-party cookies (requires Secure)

① SameSite=Strict — “Only from your own site.”

Strict means the cookie is sent ONLY when navigating inside the same site.

For example, a cookie from example.com will:

• ✔ Send when browsing inside example.com
• ✘ NOT send when coming from another site’s link
• ✘ NOT send inside iframes, images, or scripts

This is very secure, but too strict for most login-based websites — because clicking a link from another site would break the session.

② SameSite=Lax — “Mostly strict, but allow normal navigation.”

Lax is the default behavior in Chrome.

It works like Strict, except in one situation:
when the user clicks a normal link from another website.

• ✔ Link click from another site → cookie is sent
• ✘ iframe, img, script → cookie NOT sent

This keeps basic login flow working while reducing unnecessary tracking.

③ SameSite=None — “Allow third-party cookies.” (Requires Secure)

SameSite=None is used when you need a cookie to be sent in third-party contexts — like ads, analytics, embedded widgets, or external login systems.

However, there is a strict rule:

SameSite=None must also include Secure → cookies only sent over HTTPS.

If you forget this, you get errors like:

This Set-Cookie was blocked because it had the “SameSite=None” attribute but did not have “Secure”.

Quick Visual Summary

┌─────────────────────────────────────┐
│ SameSite=Strict                     │
│ → Only sent within the same site    │
│ → Most restrictive                  │
└─────────────────────────────────────┘

┌─────────────────────────────────────┐
│ SameSite=Lax (default)              │
│ → Sent only on top-level navigation │
│ → Link clicks allowed               │
└─────────────────────────────────────┘

┌─────────────────────────────────────┐
│ SameSite=None; Secure               │
│ → Third-party cookies allowed       │
│ → HTTPS required                    │
└─────────────────────────────────────┘

Why Was SameSite Introduced?

The reason is simple:

Old-style cookies allowed tracking everywhere.

• Ad companies could follow users across multiple domains
• Security risks like CSRF were easier to exploit
• Browsers had no clear rules for third-party cookies

SameSite gives browsers strict guidelines that protect user privacy without breaking most websites.

When Developers Must Care About SameSite

You must handle SameSite manually in cases like:

• External login (Google, Twitter, etc.)
• Embedding iframes or widgets
• Using multi-domain apps (auth.example.com → app.example.com)
• Payment redirects (Stripe, PayPal)

Forgetting SameSite=None; Secure is a common cause of broken login sessions.

Conclusion: SameSite Is a Privacy Filter for Cookie Sending

• Strict → only same-site
• Lax → default, link clicks allowed
• None → third-party allowed, Secure required

Once you understand these three rules, SameSite is no longer confusing — it’s simply a safety filter that prevents cookies from being sent in situations where they shouldn’t.