What Is a Cookie?

HTTP is a stateless protocol: every request the browser sends to a server stands on its own, with no memory of the one before it. Cookies exist to fix that. When you visit a site, the server can include a Set-Cookie header in its response, a name-value pair with an optional expiration date, domain, and security attributes.

The browser stores that small file and sends it back automatically in the Cookie header on every later request to the same domain. That is how an online store remembers what is in your cart between pages, and how a site keeps you logged in without asking for your password on every click. RFC 6265, the technical standard behind it, describes cookies as a state management mechanism layered on top of a protocol that has none of its own.

Not every cookie serves the same purpose. Some are required for the site to work at all, like session or cart cookies. Others just store preferences such as language or currency, and some exist purely to measure traffic or serve ads. That last group is what technical SEO cares about most, since it decides which scripts load before or after the user has given consent.

The line between the two has nothing to do with what the cookie stores. It comes down to who sets it and from which domain it's served. The same analytics vendor can run as a first-party cookie when configured on the site's own domain, or as a third-party cookie when its script loads directly from the vendor's domain.

A session cookie carries no expiration date: it lives only while the browser stays open and disappears once you close it. It's what keeps a half-filled form or an active login intact. A persistent cookie, by contrast, carries an Expires or Max-Age attribute and survives for days, months, or years, until that date arrives or the user clears it manually.

The SameSite attribute decides whether a cookie also travels on requests coming from another domain. With Strict, it only goes out on requests that originate from the site itself; with Lax, the default in most modern browsers, it's also sent when the user navigates directly to the page; with None, it travels in any context, but requires the Secure attribute and an HTTPS connection. This control exists as a direct response to CSRF attacks, where a malicious site exploited the fact that browsers sent another site's session cookie along without the user noticing.

Alongside SameSite, two more attributes close the gap: HttpOnly stops JavaScript from reading the cookie in the browser, and Secure forces it to travel only over HTTPS. When a third-party cookie gets blocked, some advertisers fall back on alternatives such as the tracking pixel or fingerprinting, each with its own technical and legal limits.

In the EU, setting any cookie that isn't strictly necessary for the site to function requires the user's prior consent, under Article 5.3 of the ePrivacy Directive (2002/58/EC). If that cookie also allows identifying a person, GDPR kicks in as the data protection framework on top. That's why a cookie banner that actually blocks scripts until the user decides serves a real legal function, beyond how it looks.

Browsers have shifted their stance on third-party cookies more than once. Safari has blocked them by default since 2020 through Intelligent Tracking Prevention, and Firefox has done the same since 2019 through Enhanced Tracking Protection. Chrome, which had spent years announcing their removal, reversed course: in April 2025 Google confirmed third-party cookies would stay without the extra consent prompt it had planned, and in October 2025 it retired most of the Privacy Sandbox APIs it had built as a replacement, after the industry barely adopted them.

For anyone running a website, that has a practical takeaway: first-party cookies remain the more stable foundation for analytics and personalization, while relying on third-party cookies means accepting that Safari and Firefox will keep blocking them regardless of what Chrome does. A technical SEO audit should check which cookies load before consent is given, a common mistake that hurts both compliance and page speed.

• Classify every cookie by purpose, necessary, preferences, statistics, or marketing, before writing the cookie policy, not after the fact.
• Set SameSite=Lax as the default and reserve None only for cookies that genuinely need to work across domains.
• Add Secure and HttpOnly to every session cookie to cut the risk of theft through a malicious script.
• Block third-party scripts from loading until the user gives explicit consent; delaying only the cookie itself isn't enough.
• Give persistent cookies a realistic expiration: a preference cookie doesn't need to live for two years if the user might change their mind sooner.
• Document the real name of each cookie, its provider, and its lifespan in the cookie policy, not a generic category description.

• Loading the analytics or tracking pixel script before the user has consented, even while the cookie banner is already visible on screen.
• Confusing "first-party cookie" with "privacy-friendly": a first-party cookie can still collect sensitive data if it isn't designed carefully.
• Setting session cookies without Secure on sites that still serve part of their content over plain HTTP, exposing the session on unencrypted networks.
• Assuming Chrome already killed third-party cookies, a belief that's circulated since 2020 and one Google itself corrected in April 2025.
• Setting SameSite=None on every cookie just in case, which widens the CSRF attack surface for no real reason.