Best practices

What is a session cookie? Definition, examples and consent rules

Article contents

Session cookies are the most common cookies on the web and the least visible. You rarely notice them, they disappear on their own, and yet they are what make logins and shopping carts work. This article explains what a session cookie is, how it works, how it differs from a persistent cookie, when it needs consent and how to find the session cookies your site sets. For the bigger picture (first-party and third-party cookies, purposes, the law), start with our guide to what cookies are and the types of cookies.

A session cookie (also called a transient, temporary or in-memory cookie) is an HTTP cookie that lives only for the duration of a browsing session. Technically, the only thing that makes a cookie a session cookie is what it lacks: the server sends the cookie without an Expires date and without a Max-Age value. The browser then keeps it in memory and discards it when the session ends.

Here is what the server sends in a typical case:

```

Set-Cookie: PHPSESSID=8f2c1a9e7b; Path=/; Secure; HttpOnly; SameSite=Lax

```

The same cookie with Max-Age=2592000 added would become a persistent cookie, kept for 30 days whether or not you close the browser.

A session cookie usually contains no personal data in clear text. It holds a random identifier (a session ID), and the information itself (who you are, what is in your cart) stays on the server, attached to that identifier.

How do session cookies work?

  1. You open a page. The server creates a session, generates a random ID and sends it in a Set-Cookie header with no expiry.
  2. The browser stores the cookie in memory for that site.
  3. On every following request to the same site, the browser sends the cookie back in the Cookie header.
  4. The server reads the ID, finds the matching session and knows that you are the person who logged in or added a product to the cart a minute ago.
  5. When the session ends, the browser forgets the cookie. The server-side session also expires after a period of inactivity defined by the site.

HTTP is a stateless protocol: without this mechanism, each page load would be a stranger to the server. Session cookies give the site a short memory, limited to the visit.

When does a browser session end?

This is where the textbook definition meets reality. MDN, the reference documentation for web developers, notes that the browser decides when the session ends, and that many browsers have a session restore feature. If you use Chrome's "Continue where you left off" or Firefox's "Open previous windows and tabs", your session cookies can survive a browser restart and come back as if you had never closed it. On mobile, where apps are rarely closed, a session can last for days. A session cookie is therefore short-lived in principle, not always in practice.

Examples of session cookies

Most server frameworks set a session cookie by default:

  • PHPSESSID: the PHP session cookie. PHP's default session.cookie_lifetime is 0, which means "until the browser is closed".
  • JSESSIONID: the session identifier used by Java servers such as Tomcat.
  • ASP.NET_SessionId: the session cookie of ASP.NET applications.
  • connect.sid: the default name used by express-session in Node.js, which sets no expiry unless the developer adds one.

Typical uses: keeping a user logged in during a visit, holding the contents of a cart before checkout, carrying the steps of a multi-page form, protecting forms against cross-site request forgery, and routing a visitor to the same server behind a load balancer.

Be careful with names. A cookie with "session" in its name is not necessarily a session cookie. Google Analytics 4 sets _ga_<container-id> to keep the state of your analytics session, but it lasts 2 years by default, as explained in our article on the _ga, _gid and _gat cookies. Only the expiry attributes decide.

Session cookies vs persistent cookies

A persistent cookie has an Expires date or a Max-Age value. It stays on the device until that date, even after the browser is closed, unless the user deletes it. The differences, point by point:

  • Lifespan: a session cookie ends with the browsing session; a persistent cookie lasts until its expiry date, from a few minutes to several years.
  • Storage: session cookies are kept in memory; persistent cookies are written to disk.
  • Typical uses: session cookies handle logins, carts and forms during a visit; persistent cookies remember preferences, "keep me signed in" logins and analytics or advertising identifiers across visits.
  • Tracking power: a session cookie can follow you through one visit; a persistent cookie can recognize you over weeks or months.

Persistent cookies raise the question of how long is too long. The CNIL recommends a maximum of 13 months for cookies that require consent, which we cover in our article on cookie retention periods.

The rule comes from Article 5(3) of the ePrivacy Directive: storing or reading information on a user's device requires consent, unless it is strictly necessary to provide the service the user explicitly requested (or solely to carry out a transmission). Lifespan is not a criterion. Purpose is.

In its Opinion 04/2012 on the cookie consent exemption, the Article 29 Working Party (now the EDPB) gave examples of exempt cookies. Several are session cookies by nature:

  • user-input cookies that keep track of what you type in a form or put in a cart, for the duration of the session;
  • authentication cookies that keep you logged in during a session;
  • user-centric security cookies, such as those detecting repeated failed logins;
  • load-balancing session cookies;
  • multimedia player session cookies that store technical data needed to play video or audio.

The same opinion says that a session cookie used for another purpose, such as tracking, is not exempt. The CNIL's 2020 guidelines take the same line and list comparable examples of trackers exempt from consent: authentication, shopping cart, interface personalization and load balancing.

In practice:

  • A PHPSESSID that only keeps a user logged in: strictly necessary, no consent needed, but it must still be listed in your cookie policy.
  • An analytics or advertising tool that sets a session cookie to group page views: consent required, before the cookie is set.
  • A chat widget that sets a session cookie before the visitor opens the chat: worth checking, because it serves no request the visitor has made yet.

Not sure what your site sets on the first page load? Run the free cookie scanner: in 30 seconds it shows which cookies your site sets before any consent.

How to see and delete session cookies

In your browser. Open the developer tools (F12), then the Application tab in Chrome or Edge, or the Storage tab in Firefox, and select Cookies. In the expiry column, session cookies are shown as "Session" instead of a date.

To delete them. Closing every browser window removes session cookies, unless session restore is turned on. To be sure, clear the cookies for the site from the browser settings, or use a private window, whose cookies are deleted when it is closed.

On your own site. Open a private window, load your home page without clicking the banner and list the cookies. Every cookie present at this point, session or persistent, should be strictly necessary. Anything else is set too early.

Security: protecting session cookies

Because a session cookie often proves who you are, stealing it lets an attacker take over the session. Common protections:

  • HttpOnly: the cookie cannot be read by JavaScript, which limits theft through injected scripts.
  • Secure: the cookie is only sent over HTTPS.
  • SameSite=Lax or Strict: the cookie is not sent with most cross-site requests, which reduces cross-site request forgery.
  • A new session ID after login: the OWASP Session Management Cheat Sheet recommends regenerating the identifier when privileges change, to block session fixation.
  • A server-side timeout: the session should expire after inactivity, whatever the browser does with the cookie.

The GDPR's transparency principle and the ePrivacy rules apply to all cookies, exempt or not. Your cookie policy or cookie declaration should list each session cookie with its name, provider, purpose, category and a duration shown as "Session". Strictly necessary session cookies belong in the necessary category described in our guide to GDPR cookie categories, and the visitor should be told they cannot be refused because the site would not work without them.

How FlowConsent handles session cookies

FlowConsent is a consent banner that treats session cookies by purpose, not by lifespan. Its automatic cookie scan detects the cookies your site actually sets and carries over the observed domain, duration and type, so a session cookie shows up as such. Cookies from known services are classified with their category; your own first-party cookies, such as a cart session set by your backend, can be added by hand with their name, purpose and duration. Every non-essential script stays blocked until the visitor consents, and each choice is stored as exportable proof, hosted in Europe. FlowConsent is free up to 25,000 sessions per month and installs in about ten minutes. The cookie declaration documentation shows how the list is built.

Questions

Common questions on this topic.

Can't find your question? Write to us, we answer fast.

What is the difference between session cookies and persistent cookies?

A session cookie has no expiry date, so the browser deletes it when the browsing session ends, usually when you close it. A persistent cookie has an Expires or Max-Age attribute and stays on your device until that date, even after a restart. Session cookies handle logins and carts during a visit; persistent cookies remember preferences and analytics or advertising identifiers across visits.

Do session cookies need consent under GDPR?

Not always. Under Article 5(3) of the ePrivacy Directive, what matters is purpose, not lifespan. A session cookie that is strictly necessary for a service the user requested, such as a login, a shopping cart or load balancing, is exempt. A session cookie used for analytics, advertising or tracking needs consent before it is set, even if it disappears when the browser closes.

What are some examples of session cookies?

Common examples are PHPSESSID (PHP), JSESSIONID (Java servers such as Tomcat), ASP.NET_SessionId (ASP.NET) and connect.sid (express-session in Node.js). They hold a random session ID that lets the server keep you logged in, remember your cart or carry a multi-step form. Note that a name containing "session" proves nothing: GA4's _ga_ cookie stores session state but lasts 2 years.

How do I get rid of a session cookie?

Close every browser window: session cookies are deleted when the browsing session ends. If your browser restores your previous session on startup, such as Chrome's Continue where you left off, they may come back, so clear the site's cookies from the browser settings instead. A private window is the simplest option: all its cookies, session or persistent, are deleted when you close it.

Are session cookies safe?

Session cookies usually hold only a random ID, not personal data in clear text, and they disappear quickly. The main risk is session hijacking: whoever steals the cookie can act as you on the site. Websites reduce this risk with the HttpOnly, Secure and SameSite attributes, a new session ID after login and a server-side timeout. As a user, logging out on shared devices also ends the session.

Make your site compliant today.

Free up to 25,000 sessions a month. No credit card, no commitment.