Skip to Content

Learn · Cookies

Cookies

What Is a Cookie?

We love Sesame Street's Cookie Monster, and we all love cookies — but these are a different kind of cookie.

A cookie is a small piece of text a website asks your browser to store and send back on the next request. HTTP itself has no memory — every request arrives as if it were the first. Cookies are how a site recognizes that this request came from the same browser as the last one.

That mechanism is neutral. It is what keeps you signed in, and it is also what lets an advertising network recognize you on an unrelated site. The difference is not the technology; it is who set the cookie and what they do with it.

First-Party vs Third-Party

A first-party cookie is set by the site in your address bar. A third-party cookie is set by some other domain whose code the page loaded — an ad network, an analytics provider, an embedded video.

Third-party cookies are the ones that historically enabled cross-site profiling, because the same third party appears on thousands of sites and sees the same identifier each time. Browsers have been restricting them for years; many now block or partition them by default.

Why Deleting Every Cookie Logs You Out

Because your session is a cookie. "Clear all cookies" is a blunt instrument: it removes the advertising identifier and your bank login in the same stroke.

Sessyn's "Clear Known Trackers" button is the alternative: it only removes a cookie Sessyn has a sourced catalog entry for and knows is not necessary — _ga, _fbp and the like. A cookie with no catalog entry is left alone rather than guessed about, because SID and HSID are real Google session cookies and wrongly clearing one locks you out of the account it belongs to. That asymmetry — a privacy miss versus a lockout — is why the button is scoped to evidence, never to a guess about what a cookie's name or shape implies.

The Attributes That Matter

AttributeWhat it doesWhy you should care
HttpOnlyHides the cookie from JavaScriptStops a cross-site scripting bug from stealing your session
SecureOnly sent over HTTPSPrevents interception on a hostile network
SameSiteControls sending on cross-site requestsThe main defense against cross-site request forgery
DomainWhich hosts receive itA host-only cookie is narrower and safer than a whole-domain one
Max-Age / ExpiresHow long it survivesA session cookie dies when you close the browser; a persistent one may last years

SameSite, Specifically

SameSite=Strict means the cookie is never sent when you arrive from another site — safe, but it can log you out when you follow a link in. SameSite=Lax is the common middle ground and the modern browser default. SameSite=None permits cross-site sending and requires Secure; it is the setting that makes third-party tracking cookies work.

Session vs Persistent

A session cookie has no expiry and is discarded when the browser closes. A persistent cookie carries an expiry date and survives restarts — which is what "remember me" means, and also what lets an identifier follow you for two years.

How Long Cookies Last

A site sets a cookie's lifetime with Expires (a date) or Max-Age (a number of seconds). With neither, it is a session cookie and goes when you close the browser — though a browser set to restore your last session may keep session cookies too. With either, it is stored until that time or until you delete it.

Browsers also cap how far ahead a site may set an expiry. Chrome, since version 104 (August 2022), shortens any expiry more than 400 days away to 400 days, following the draft update to the cookie standard (source: the Chrome for Developers blog, developer.chrome.com/blog/cookie-max-age-expires). A site can refresh a cookie each time you visit, so a cookie you keep seeing may be renewed long past its first expiry.

Sessyn shows each cookie's exact expiry date and time in your own date format, with a plain duration beside it, for example "Expires Oct 12, 3:40 PM · in about 13 days". It shows this on screen only; a report you send says only whether a cookie is stored or ends with the browser, because an exact expiry is close to an identifier.

Why a Login Can End Before Its Cookie Expires

A sign-in cookie usually holds a session identifier, and the site keeps the session itself on its servers. The site decides when that session ends: after a period of inactivity, after a fixed time, when you sign out on another device, or when you change your password. Once it does, the cookie still sits in your browser until its expiry, but it no longer signs you in.

That is why Sessyn says your sign-in is set to last until a date, never that it will — the expiry is the latest the browser will keep it, and the site can end it sooner on its side.

Why Sessyn Shows No Creation Date

Browsers tell extensions a cookie's name, domain, path, attributes and expiry. They do not tell an extension when a cookie was created or last used. Sessyn could work out a first-seen time by noting each cookie as it appears, but that log would be a record of which sites you visited and when — exactly the browsing record Sessyn refuses to keep. So it does not.

Host-Only vs Subdomains

A cookie set without a Domain is host-only: the browser returns it to that exact host and nowhere else. A cookie set for the whole domain, shown with a leading dot such as .example.com, is sent to every subdomain as well, so more of the site's servers see it.

Partitioned Cookies

A Partitioned cookie (sometimes called CHIPS) is stored separately for each top-level site. An embedded service still gets a cookie on each site that loads it, but the copy on one site cannot be read on another, so it cannot link your visits across them.

CSRF Tokens

Cookies named like csrftoken or XSRF-TOKEN usually hold a cross-site request forgery token: a random value the site checks to prove a form was sent from its own pages rather than forged by another site. It identifies nothing about you, and removing it can break sign-in or checkout until the page reloads.

Last reviewed: 2026-09-29