Guides / Concepts explained

What Are Cookies? How Websites Remember You

Cookies are small pieces of data a website stores in your browser to remember you. How logins, carts and tracking use them, and what to ask your AI builder.

Mythex Team · 2026-09-29 · 5 min read

A cookie is a small piece of text that a website asks your browser to store and then send back on every later visit to that site. It's how a website "remembers" you — that you're logged in, what's in your cart, which language you picked. Cookies are just data, not programs, but because they can identify you, they matter for both security and privacy.

Why it matters when you build with AI

Cookies sit underneath several features you'll ask an AI builder for, often without the word "cookie" ever coming up:

• Login. In most web apps, "stay logged in" means a session cookie. How that cookie is configured decides how easy it is to steal.
• Carts and preferences. A basket that survives a page refresh often relies on a cookie or on browser storage.
• Analytics and ads. Adding Google Analytics, a Meta pixel or a chat widget usually adds cookies from other companies.
• Legal notices. In many places, some cookies need the visitor's consent first, which is where cookie banners come from.

If you know which cookies your app sets and why, you can make better choices about security settings, consent and your privacy policy.

An everyday analogy

Think of a cloakroom ticket. You hand over your coat and get a numbered ticket. The ticket doesn't contain your coat — just a number. Every time you come back to the counter you show the ticket, and the attendant knows which coat is yours.

A session cookie works the same way. When you log in, the server keeps your details on its side and gives your browser a ticket — a long random ID. Your browser shows that ticket with every request, and the server looks up who you are. Anyone who copies the ticket can collect the coat, which is why login cookies need protecting.

How a cookie actually works

1. You visit a site. The server's response includes a header like Set-Cookie: session_id=8f3k...; HttpOnly; Secure; SameSite=Lax.
2. Your browser stores it, tied to that site's domain.
3. On every later request to the same site, the browser automatically adds Cookie: session_id=8f3k....
4. The server reads it and knows it's you.

The page's JavaScript can also create cookies, but the most important ones — login sessions — should be set by the server and hidden from JavaScript.

Types of cookies

Browsers have steadily restricted third-party cookies because they're used to track people across websites. Several major browsers now block many of them by default, and the details keep changing, so don't build anything important on third-party cookies.

A worked example: a small online shop

Say you've built a shop selling handmade candles. Here are the cookies a sensible version would set, and why.

session — set when the owner or a customer logs in. It holds only a random ID; the server keeps the real session data. Settings: HttpOnly (page scripts can't read it), Secure (only sent over HTTPS), SameSite=Lax (not sent on most requests started by other sites). Strictly necessary.

cart_id — lets a visitor who isn't logged in keep their basket. It points to a cart saved in the database. Strictly necessary, because the visitor asked to add things to a cart.

theme — remembers dark mode. This could be a cookie, but it never needs to reach the server, so browser localStorage is simpler.

Analytics cookies — added if you install an analytics tool. These are non-essential. In the EU and UK they generally require consent before they're set, so the analytics script should wait until the visitor clicks "Accept".

Notice what the shop does not store in cookies: the customer's name, address or card details. Cookies travel with every request and live on the user's device, so they should hold IDs, not personal data.

Common terms explained

Common mistakes and misconceptions

• "Cookies are viruses." They're plain text. They can't run code on your computer.
• Putting sensitive data in cookies. Store a random ID and keep the details on the server.
• Login tokens in localStorage. Any script running on the page can read localStorage, including an injected one. An HttpOnly cookie can't be read by page scripts at all.
• Missing Secure and HttpOnly. These two flags are cheap and close common holes.
• Assuming a banner covers everything. A banner that loads analytics before anyone clicks "Accept" doesn't do its job.
• Forgetting logout. Logging out should delete the cookie and end the session on the server, so a copied cookie stops working.
• "If I don't use cookies, privacy rules don't apply." Rules like the GDPR cover personal data wherever it's stored — local storage, device fingerprints and server logs included.

What to ask your AI builder for

• "List every cookie the app sets, what it's for, how long it lasts, and whether it's strictly necessary."
• "Use an HttpOnly, Secure, SameSite=Lax cookie for the login session. Don't put auth tokens in localStorage."
• "Keep only a random session ID in the cookie; store session data on the server."
• "On logout, clear the cookie and invalidate the session on the server."
• "Don't load analytics or marketing scripts until the visitor accepts them, and remember their choice."
• "Add a simple cookie section to the privacy policy that matches the list above."

For the consent part, see how to add cookie consent. For how cookies fit into logins, read what authentication is.

Cookies in Mythex

Mythex doesn't provide a built-in login for your app's users, so the cookies your app sets come from its own code and the tools you add to it — for example, a session cookie from the auth approach you pick. Ask the agent in chat to list them, tighten their settings, or add a consent banner, and check the result in the live preview before you publish. The docs recipe on adding login to your app is a good starting prompt, and security for apps you build covers keeping keys and secrets out of the browser.