HTTP Cookies: State for a Stateless Web
Think of a cookie as a server's nametag for your browser. Since HTTP is stateless, this nametag helps the server remember you across requests for logins, shopping carts, or personalization. The main footgun is security: always use security flags.
Why it exists
HTTP is a stateless protocol. Each request from a client to a server is an independent transaction, unrelated to any previous requests. This makes tasks like keeping a user logged in or remembering items in a shopping cart impossible without a way to maintain state. Cookies were created to solve this by letting a server store small pieces of information on the client.
The mental model
A cookie is like a coat-check ticket. You give your identity to the server, and it gives you a ticket (the cookie) to hold onto. On your next visit, you present the ticket, and the server can retrieve your session details without having to remember you personally. The browser is responsible for holding the ticket and showing it every time you talk to that specific server.
How it works
The process uses two HTTP headers. First, when a server wants to create a cookie, its response includes a Set-Cookie header with a key-value pair and optional attributes (like Expires, Max-Age, Domain, Path, Secure, HttpOnly, SameSite). For every subsequent request to that same server, the browser automatically includes a Cookie header containing all relevant key-value pairs. The server reads this header to "remember" the client.
When to use it
Use cookies for managing user sessions, like keeping a user logged in after they authenticate. They are also suitable for storing user preferences, such as a chosen theme (dark/light mode) or language. Another common use is for tracking user behavior across a site for analytics purposes.
When not to use it
Avoid storing large amounts of data in cookies; browsers have size limits (typically around 4KB). Never store highly sensitive information like passwords or credit card numbers directly in a cookie. For client-side state that doesn't need to be sent to the server on every request, consider using Web Storage APIs like localStorage or sessionStorage instead.
One canonical example
A user logs into a site. The server verifies their credentials, creates a session ID, and sends it back in a response header: Set-Cookie: session_id=abc123xyz; HttpOnly; Secure. For all future requests to that site, the browser automatically sends Cookie: session_id=abc123xyz. The server uses this ID to look up the user's session data and confirm they are still logged in.
Interview question
How do HTTP cookies enable a server to maintain a user's logged-in state across multiple requests?
- a.By sending a unique session identifier to the browser, which then returns it with subsequent requests.Correct
- b.By storing the user's complete session data directly within the cookie on the client side.
- c.By maintaining a continuous, open connection between the client and server to track user activity.
- d.By requiring the user to re-authenticate with credentials for each new request to verify their identity.
Why? this is the answer
The card explains that a cookie is like a 'coat-check ticket' or 'session_id' that the server gives to the browser. The browser then returns this identifier, allowing the server to look up the user's session details. Storing complete session data directly in the cookie (option B) is incorrect and generally avoided due to size limits and security concerns.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
- #web
- #http
- #state
- #browser-api
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles