One attribute decides everything
Cookies split into two types by how long they live, and a single attribute settles which type a cookie is. If a cookie is written with an Expires date or a Max-Age value, it's persistent. If it has neither, it's a session cookie. That's the entire distinction, and the browser applies it automatically.
This is a different axis from first-party versus third-party, which is about who sets the cookie. Lifespan is about how long it stays. A cookie can be first-party and persistent, third-party and session, or any other combination. If the ownership side is what you're after, read first-party vs third-party cookies instead.
Session cookies: gone when you leave
A session cookie has no expiry attribute, so the browser holds it only for the current browsing session and deletes it when that session ends, typically when you close the browser. It lives in memory rather than on disk. These are the cookies that carry short-lived, in-the-moment state: the contents of a cart before checkout, a logged-in session, a multi-step form's progress, a fraud-prevention token. Because they disappear on their own and don't follow you between visits, session cookies are the lower-risk half of the pair.
One caveat: "session" for a browser isn't always what a user expects. Features like Chrome's tab restore or "continue where you left off" can preserve session cookies across a restart, so the deletion isn't always instant.
Persistent cookies: they wait for you
A persistent cookie carries an Expires date or Max-Age, so it survives closing the browser and stays until it either expires or you clear it. These handle anything that needs to outlast a single visit: a "remember me" login, a saved language or currency, an accessibility preference, or a long-lived analytics or advertising ID. Persistent cookies are more useful for recognising returning visitors, which is exactly why they carry more privacy weight and draw more regulatory attention.
Session vs Persistent Cookies
| Aspect | Session | Persistent |
|---|---|---|
| Expiry attribute | None | Has Expires or Max-Age |
| Survives browser close? | No | Yes, until expiry |
| Where it's stored | In memory | On disk |
| Typical use | Cart, live session, form step | "Remember me", preferences, analytics ID |
| Privacy weight | Lower | Higher |
Browsers cap how long persistent means
"Persistent" no longer means "forever." Browsers now put ceilings on cookie lifetimes. Chrome caps the maximum age of a cookie at 400 days. Safari's Intelligent Tracking Prevention is stricter: any cookie written by JavaScript through document.cookie is limited to a 7-day lifetime, and as little as 24 hours for domains classified as trackers. So a persistent cookie your script asks to keep for a year may quietly be trimmed to a week on Safari. Cookies set server-side through the Set-Cookie header avoid that particular JavaScript cap.
Duration is a compliance choice as much as a technical one
The GDPR's data-minimisation principle means you shouldn't keep a cookie longer than the purpose needs. France's CNIL recommends a consent lifespan on the order of 6 months, and treats cookie durations beyond around 13 months as hard to justify. Setting a tracking cookie to expire in 2038 isn't clever, it's a finding waiting to happen. Disclose each cookie's real duration in your cookie policy.
What this means for your site
Both session and persistent cookies need consent when they're non-essential, so the lifespan doesn't decide whether you need permission, only how long the effect of that permission lingers. When you run a cookie audit, record each cookie's expiry alongside its purpose. CookieBeam's scanner reports the duration of every cookie it finds, which makes it easy to spot the persistent trackers hiding among your necessary session cookies and to write a cookie policy that states real durations rather than guesses.
How to tell which is which
You don't have to guess. Open your browser's developer tools, go to the Application (Chrome) or Storage (Firefox) panel, and look at the cookies for the site. The Expires / Max-Age column tells you directly: a value of "Session" means it dies with the browser session, an actual date means it's persistent. Running this on your own site is a fast reality check, and it's usually where owners discover a supposedly "functional" cookie is actually a persistent analytics ID set to last a year.
Are session cookies automatically safe?
They're lower-risk, not risk-free. A session cookie still needs consent if its purpose is non-essential, and session-scoped analytics exists. The lifespan reduces how long you can be recognised, but it doesn't change the purpose test. The safe reading is: session versus persistent tells you how long the cookie can follow someone, while necessary versus non-essential tells you whether you need permission at all. You need both lenses. Duration feeds your data-retention story; category feeds your consent story, and your cookie policy should state both for every cookie you set.
Setting the right lifespan
If you set cookies, match the duration to the job rather than defaulting to the maximum. Authentication and cart state work fine as session cookies, so a login doesn't need a year-long persistent token. Preferences a returning visitor benefits from can be persistent, but measured in months, not decades. Picking sensible expiries isn't only good privacy hygiene, it's what data-minimisation asks for, and it keeps your cookie table honest when a regulator or a customer reads your policy.