What Is a Cookie? How Websites Remember You
Cookies are how you stay logged in, keep items in a cart, and — yes — get tracked across the web. What a cookie is, how session cookies work, first- vs third-party cookies, the security settings every login cookie needs, and cookies vs local storage.
You log in to a site, close the tab, come back tomorrow, and you're still logged in. The site remembered you. It did that with a cookie — and so does almost every app with a login.
The problem cookies solve
The web's basic protocol, HTTP, has no memory. Every request your browser sends is independent: the server has no built-in way to know that the request for /dashboard came from the same person who logged in a second ago.
Cookies add that memory.
What a cookie is
A cookie is a small piece of text a website asks your browser to store, and which the browser then sends back automatically with every request to that site.
- You log in. The server checks your password and replies with:
Set-Cookie: session=abc123xyz; HttpOnly; Secure; SameSite=Lax - Your browser stores
session=abc123xyz. - On every later request to that site, the browser adds:
Cookie: session=abc123xyz - The server looks up
abc123xyz, sees it belongs to you, and shows your dashboard.
That value is a session ID — a long random string acting as a temporary key to your account. Whoever has it is you, as far as the site is concerned. That's why cookie security matters.
What cookies are used for
- Staying logged in — session cookies.
- Preferences — language, dark mode, currency.
- Shopping carts — items remembered between visits.
- Analytics — recognising returning visitors.
- Advertising and tracking — following you across sites.
First-party and third-party cookies
- A first-party cookie is set by the site you're visiting. Login and cart cookies are first-party.
- A third-party cookie is set by a different domain embedded in the page — an ad network, a social media button. Because that same third party is embedded on many sites, it can recognise you across all of them. That's cross-site tracking.
Safari and Firefox block third-party cookies by default, and privacy laws regulate them. For your own app, stick to first-party cookies and you'll avoid most of the headaches. (GDPR Basics for App Builders.)
Session vs persistent cookies
- A session cookie has no expiry date and is deleted when the browser closes (though some browsers restore them).
- A persistent cookie has an expiry —
Max-Age=2592000for 30 days — and survives restarts. "Remember me" checkboxes usually mean a persistent cookie.
The security settings every login cookie needs
If your app sets its own login cookie, these attributes matter. (If you use a login service or library, it should set them for you — check that it does.) (How to Add Login to an AI-Built App.)
| Attribute | What it does | Why |
|---|---|---|
HttpOnly |
JavaScript on the page can't read the cookie | Stops malicious scripts from stealing the session (What Is XSS?) |
Secure |
Only sent over HTTPS | Stops it being read on insecure connections (What Is HTTPS?) |
SameSite=Lax |
Not sent on most requests started by other sites | Protects against forged requests from other sites |
Max-Age / Expires |
When it expires | Sessions shouldn't live forever |
And on the server side: session IDs must be long and random, and logging out must invalidate the session on the server, not just delete the cookie in the browser.
Cookies vs local storage
Browsers also offer local storage, a simple place for JavaScript to save data. AI-generated apps often put login tokens there. The differences:
| Cookies | Local storage | |
|---|---|---|
| Sent to server automatically | Yes | No — code must attach it |
| Readable by page JavaScript | Not if HttpOnly |
Always |
| Size | ~4 KB each | ~5 MB |
| Expiry | Configurable | Never, unless cleared |
For login sessions, an HttpOnly cookie is generally safer, because a malicious script injected into your page can read anything in local storage — including a token that lets it act as the user. Local storage is fine for harmless preferences like a theme setting.
Seeing your cookies
Open your browser's developer tools → Application (Chrome/Edge) or Storage (Firefox) → Cookies. You'll see every cookie for the site, its value, expiry, and flags. (Browser Developer Tools for Beginners.)
Handy when debugging "I keep getting logged out": check whether the cookie is set, whether it has the right domain, and whether it's expiring.
Do I need a cookie banner?
If your app only uses cookies that are strictly necessary — login, cart, security — most privacy laws, including those in the EU and UK, don't require consent for them. Analytics and advertising cookies generally do. Privacy-friendly analytics tools that don't use cookies can avoid the banner entirely. (Analytics for Beginners.) This isn't legal advice; check the rules where your users are.
EasySpawn serves every app over HTTPS on your own domain from day one, so Secure first-party cookies work in production exactly as they should. See how it works or join the waitlist.
Related: Authentication vs Authorization · What Is a JWT? · Does My App Need a Privacy Policy? · localStorage vs sessionStorage vs Cookies
Keep reading
Do You Need a Cookie Banner? A Plain-English Guide for Small Apps
Cookie banners are required when you set non-essential cookies or trackers for EU and UK visitors — not for every cookie. What counts as essential, when you need consent, what a compliant banner must do, and how to avoid needing one at all.
The OWASP Top 10 (2025) Explained for Beginners and App Builders
The OWASP Top 10 is the most widely used list of web application security risks. All ten 2025 categories in plain English — from broken access control to supply chain failures — with what each looks like in an AI-built app and how to prevent it.