Types of Cookies: A Complete Technical Guide

Not all cookies are created equal. The type of cookie determines how long it persists, who can read it, how securely it travels, and — critically — whether it requires user consent. Understanding these distinctions is essential for both compliance and implementation.

Session Cookies vs. Persistent Cookies

The most fundamental distinction is how long a cookie lasts.

Session Cookies

A session cookie exists only for the duration of a browser session. It has no Expires or Max-Age attribute. When the user closes their browser, the cookie is deleted.

Set-Cookie: cart_id=xyz789; Path=/; Secure; HttpOnly

Session cookies are typically used for:

• Maintaining login state during a visit
• Shopping cart contents
• CSRF protection tokens
• Multi-step form data

Because session cookies do not persist, they are generally less invasive from a privacy perspective. However, they still require consent if they are not strictly necessary for the service the user has requested.

Persistent Cookies

A persistent cookie has an explicit expiration date. It survives browser restarts and remains on the user's device until it expires or is manually deleted.

Set-Cookie: preferences_lang=en; Path=/; Max-Age=31536000; Secure

This cookie will persist for one year (31,536,000 seconds). Common uses include:

• Remember-me login functionality
• Language and theme preferences
• Analytics identifiers (Google Analytics cookies persist for up to 2 years)
• Advertising tracking (some ad cookies persist for 13 months or more)

Persistent cookies are subject to greater scrutiny under privacy regulations. The CNIL (France's data protection authority) has recommended a maximum cookie lifetime of 13 months, and consent must be renewed at least every 13 months as well.

First-Party vs. Third-Party Cookies

This distinction is central to the privacy debate and directly affects consent requirements.

First-Party Cookies

A first-party cookie is set by the domain the user is actually visiting. If you visit example.com, any cookie set by example.com is a first-party cookie.

First-party cookies are used for core website functionality: sessions, preferences, analytics that the website operator runs themselves. They can only be read by the domain that set them.

Example: You visit shop.example.com. The server sets a cookie named session_id. This cookie is sent only to shop.example.com and its subdomains. No other website can access it.

Third-Party Cookies

A third-party cookie is set by a domain other than the one the user is visiting. When example.com loads an advertising script from ads.tracker.com, and that script sets a cookie under the tracker.com domain, that is a third-party cookie.

This is how cross-site tracking works. The tracker.com cookie is sent with every request to tracker.com, regardless of which website triggered the request. If tracker.com's scripts are embedded on 10,000 websites, they can observe the same user across all 10,000 sites.

Third-party cookies are the primary target of both regulatory enforcement and browser-level restrictions:

• Safari has blocked third-party cookies by default since 2020 (ITP)
• Firefox blocks known third-party trackers by default (ETP)
• Chrome is transitioning away from third-party cookies with its Privacy Sandbox initiative
• Regulatory enforcement actions overwhelmingly target third-party tracking cookies

Secure Cookies

A cookie with the Secure attribute is only sent over HTTPS connections. It will never be transmitted over unencrypted HTTP.

Set-Cookie: auth_token=secret123; Secure

This prevents a man-in-the-middle attacker from intercepting the cookie on an insecure connection. Any cookie that contains sensitive information — session identifiers, authentication tokens, personal data — should always be marked Secure.

From a compliance perspective, failing to use the Secure flag on sensitive cookies could be considered a failure to implement appropriate technical measures under GDPR Article 32 (security of processing).

HttpOnly Cookies

A cookie with the HttpOnly attribute cannot be accessed by JavaScript via document.cookie. It is only sent with HTTP requests to the server.

Set-Cookie: session_id=abc123; HttpOnly

This is a critical security measure. Cross-site scripting (XSS) attacks often attempt to steal cookies by injecting JavaScript that reads document.cookie. The HttpOnly flag prevents this vector entirely.

Session cookies and authentication cookies should almost always be HttpOnly. Cookies that need to be read by client-side JavaScript (such as preference cookies that affect the UI) cannot be HttpOnly.

SameSite Cookies

The SameSite attribute controls whether a cookie is sent with cross-site requests. It was introduced to mitigate cross-site request forgery (CSRF) attacks and to give sites more control over cross-site cookie behavior.

SameSite=Strict

The cookie is only sent with requests originating from the same site. If a user clicks a link on other.com that goes to your-site.com, the cookie will not be sent with that initial request.

This is the most secure setting but can break legitimate functionality. For example, if a user clicks a link to your site from an email, their session cookie would not be sent, and they would appear logged out.

SameSite=Lax

The cookie is sent with top-level navigations (clicking a link) but not with cross-site subrequests (loading images, frames, or making AJAX requests from another site). This is the default in modern browsers if no SameSite attribute is specified.

Lax provides a reasonable balance between security and usability. It prevents third-party sites from triggering authenticated actions on your site while still allowing normal link navigation to work.

SameSite=None

The cookie is sent with all requests, including cross-site requests. This is required for third-party cookies to function. A cookie set with SameSite=None must also have the Secure attribute.

Set-Cookie: tracking_id=xyz; SameSite=None; Secure

Any cookie that needs to work in a cross-site context (embedded widgets, third-party authentication, cross-site tracking) must use SameSite=None. This is increasingly relevant as browsers tighten their default cookie policies.

Zombie Cookies and Supercookies

These are worth mentioning because they represent attempts to circumvent privacy controls:

• Zombie cookies are cookies that recreate themselves after being deleted. They typically work by storing the same identifier in multiple storage mechanisms (cookies, localStorage, IndexedDB, Flash LSOs) and using whichever survives to regenerate the others. This practice is widely considered deceptive and has been the subject of enforcement actions.
• Supercookies are tracking mechanisms that operate at a level below normal cookies — such as ISP-level header injection (Verizon's UIDH) or HSTS-based fingerprinting. They are extremely difficult for users to control or delete.

Both zombie cookies and supercookies are clearly incompatible with GDPR and ePrivacy requirements. Using them would constitute a violation of the principles of transparency, lawfulness, and data minimization.

Comparison Table

Type	Lifetime	Scope	Consent Typically Required?	Key Use Cases
Session	Browser session only	First-party	Only if non-essential	Login state, cart, CSRF tokens
Persistent (1st party)	Days to years	First-party	Usually yes	Preferences, analytics, remember-me
Persistent (3rd party)	Days to years	Cross-site	Almost always yes	Advertising, retargeting, social widgets
Secure	Varies	HTTPS only	Depends on purpose	Any sensitive cookie
HttpOnly	Varies	Server-side only	Depends on purpose	Session IDs, auth tokens
SameSite=Strict	Varies	Same-site only	Depends on purpose	CSRF-sensitive operations
SameSite=Lax	Varies	Same-site + top-level nav	Depends on purpose	General session management
SameSite=None	Varies	All contexts (requires Secure)	Almost always yes	Third-party embeds, cross-site auth

What This Means for Compliance

The type of cookie directly affects your compliance obligations:

1. First-party session cookies that are strictly necessary (login sessions, shopping carts, CSRF tokens) are exempt from consent requirements under ePrivacy Article 5(3).
2. First-party persistent cookies for analytics, preferences, or functionality generally require consent — though some DPAs allow limited exceptions for first-party analytics under specific conditions.
3. Third-party cookies of any kind almost always require explicit prior consent. There are very few legitimate exceptions.
4. Security attributes (Secure, HttpOnly, SameSite) do not change consent requirements, but using them demonstrates good security practice — which is a GDPR requirement in itself.

Knowing exactly which cookies your website sets — and what type each one is — is the foundation of any compliance program. Passiro's scanner automatically identifies and classifies every cookie on your website, including third-party cookies set by embedded scripts you may not even be aware of.

Now that we understand the types, let's look at how cookies are organized into consent categories — the classification system that determines how they appear in your cookie banner.