A cookie is a small piece of text information that a web server sends to the browser via the HTTP response header Set-Cookie when a website is visited. The browser stores the cookie locally and automatically sends it back with every subsequent request to the same domain. That way a user can be recognised across multiple page views, their login status kept, or a language setting remembered, even though HTTP is stateless by design. Cookies have been a fixed part of the web since the 1990s, but today sit squarely in the tension between personalisation, tracking and privacy.
How does a cookie work?
Cookies live in the HTTP protocol. When a visitor opens a page, the server responds — in addition to the HTML page, with a Set-Cookie header:
Set-Cookie: sessionId=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
The browser places the cookie in its cookie store, organised by domain. With every following request to the same domain, it automatically attaches the header Cookie: sessionId=abc123. That’s how the server knows which user is currently browsing, without them having to identify themselves anew on every click.
Cookies are small: 4 KB per file is common, and per domain the browser typically holds around 50 cookies. They are managed exclusively by the browser – the server can only “suggest” (Set-Cookie); the decision is made on the client.
Types of cookies
Session cookies vs. persistent cookies
- Session cookies exist only while the browser is open, without an
ExpiresorMax-Ageattribute. Typical for shopping carts, login sessions, temporary filters. - Persistent cookies have a fixed expiry date (
Expires=Wed, 22 May 2027 12:00:00 GMT) and survive browser restarts. Classic for “stay signed in” functions or language presets.
First-party cookies vs. third-party cookies
- First-party cookies come from the same domain as the visited page, e.g.
aceart.desets a cookie foraceart.de. They’re generally necessary or helpful for the site’s function. - Third-party cookies are set by a different domain than the one currently visited, e.g. an ad network on an embedded advert. They are the technical backbone of classic cross-site tracking and are increasingly blocked by modern browsers (Safari ITP, Firefox ETP, Chrome by default from 2024).
Functional, statistics, marketing
In the GDPR context, cookies are usually divided into three categories:
| Category | Examples | Consent required? |
|---|---|---|
| Necessary / functional | Login session, cart, language choice, consent status | no |
| Statistics / analytics | Google Analytics, Matomo (in identifier mode) | yes |
| Marketing / tracking | Meta pixel, Google Ads remarketing, LinkedIn Insight Tag | yes |
Without effective consent, non-necessary cookies may not be set under the GDPR and Germany’s TTDSG.
Components of a cookie
A cookie consists of more than just name and value – through additional attributes the server controls lifetime, scope and security:
- Name=value: the actual content, e.g.
sessionId=abc123 - Domain: which domain gets the cookie sent back (
.aceart.deincludes subdomains) - Path: which URL paths it’s restricted to (
Path=/shop) - Expires / Max-Age: expiry timestamp or lifetime in seconds
- Secure: the cookie is only sent over HTTPS (see SSL)
- HttpOnly: the cookie can’t be read from JavaScript via
document.cookie, only via HTTP – protects against XSS theft - SameSite: controls whether the cookie is sent along with cross-site requests (
Strict,Lax,None). Protects against CSRF attacks
A modern default configuration for login sessions typically looks like this:
Secure; HttpOnly; SameSite=Lax.
Cookies and the GDPR
Since the GDPR (2018) and the ECJ’s “Planet49” ruling (2019), it’s clear in Germany: for all cookies that are not technically essential for the site’s function, an active, informed consent from the user must exist. Mere notice banners (“By using this website you agree to cookies”) are not sufficient.
A GDPR-compliant cookie banner typically fulfils:
- Categorised selection (necessary / statistics / marketing) – no pre-ticked checkboxes
- A “Decline” button equal in weight to the “Accept” button
- Cookies may only be set after consent
- Consent must be revocable
- Storage of the consent status (duration: frequently 12 months, then ask again)
In Germany, the TTDSG (Telecommunications-Telemedia Data Protection Act) has additionally regulated the legal situation around cookies and similar storage mechanisms since December 2021.
Cookies vs. local storage / session storage
HTML5 brought alternative storage mechanisms in the browser – they replace cookies in many use cases:
| Mechanism | Sent to server | Storage | Typical use |
|---|---|---|---|
| Cookie | automatically with every request | up to ~4 KB | Sessions, auth, A/B test assignment |
| LocalStorage | no | up to ~5–10 MB | UI state, caching, offline data |
| SessionStorage | no | up to ~5–10 MB | Tab-specific state |
| IndexedDB | no | large (often unlimited) | Structured data, PWA content |
For pure frontend state, LocalStorage and SessionStorage are usually the better choice – they waste no bandwidth overhead on every request. For server-side sessions, though, there’s no way around cookies.
Security aspects
Cookies are a coveted attack target because they often contain auth tokens. Typical risks and their countermeasures:
- Cookie theft via XSS → set
HttpOnly, harden content against XSS - Man-in-the-middle in unencrypted networks → set
Secure, enable HSTS - Cross-site request forgery (CSRF) →
SameSite=LaxorStrict, plus CSRF tokens - Cookie hijacking → short session lifetimes, token rotation, IP/user-agent binding
How do I manage cookies in the browser?
Every modern browser offers settings for handling cookies:
- Block all cookies: pragmatic, but breaks most websites
- Delete cookies on closing: a good compromise for privacy-conscious users
- Block third-party cookies: now the default in Safari and Firefox
- Decide per website: via the site settings in the browser
From a website operator’s perspective that means: a modern site must not assume that third-party cookies are available. Tracking and analytics increasingly rely on first-party cookies and server-side solutions.
Frequently asked questions about cookies
Are cookies dangerous?
Cookies themselves are pure text information – they can’t execute code and can’t contain a virus. They only become dangerous when a cookie with an auth token is stolen (e.g. via XSS on a poorly secured website). The protective attributes Secure, HttpOnly and SameSite address exactly that.
How long does a cookie live?
The server decides that when setting it via Expires or Max-Age. Session cookies live only until the browser closes, persistent cookies until their expiry date or until the user deletes them manually.
What happens if I disable cookies completely? Login functions, shopping carts, language selection and similar personalised features stop working or “forget” the state on every page view. Some websites refuse access entirely in that case.
Are cookies being abolished? Third-party cookies will disappear from the major browsers step by step – Safari and Firefox already block them largely, Chrome is following. First-party cookies, on the other hand, remain the backbone of classic web sessions and can’t be replaced in the foreseeable future.
What’s the difference between a cookie banner and a consent management platform? A cookie banner is the visible UI component asking for consent. A consent management platform (CMP) such as Usercentrics, Cookiebot or Borlabs controls the banner, stores the consent, blocks scripts until agreement and delivers audit-proof records.
Conclusion
Cookies are a classic web standard and at the same time one of the most heavily regulated storage elements in the browser. If you run a website, there’s no way around GDPR-compliant cookie management, not least because ineffective consent can quickly lead to legal warnings. We’re happy to support you with selecting and setting up a CMP, hardening auth cookies, or switching from third-party to first-party tracking – just drop us a line for a first assessment.