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
| Attribute | What it does | Why you should care |
|---|---|---|
| HttpOnly | Hides the cookie from JavaScript | Stops a cross-site scripting bug from stealing your session |
| Secure | Only sent over HTTPS | Prevents interception on a hostile network |
| SameSite | Controls sending on cross-site requests | The main defense against cross-site request forgery |
| Domain | Which hosts receive it | A host-only cookie is narrower and safer than a whole-domain one |
| Max-Age / Expires | How long it survives | A 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