Cookies, sessionStorage, and localStorage all store data in the browser, but they differ in size limits, expiration, and how they are sent to the server. Security and expiration differ, so choose carefully; test storage limits and cross-tab behavior.
Use this JavaScript interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.
Describe the difference between a cookie, sessionStorage and localStorage in browsersFrontend interview answer
This JavaScript interview question tests whether you can explain cookie vs localStorage vs sessionStorage: what is the difference, connect it to production trade-offs, and handle common follow-up questions.
- cookie vs localStorage vs sessionStorage: what is the difference explanation without falling back to memorized docs wording
- Cookies and Local Storage reasoning, edge cases, and production failure modes
- How you would answer the most likely JavaScript interview follow-up
The Core Idea
Browsers provide several ways to store data on the client side. The three most common are:
- Cookies – small pieces of data sent to and from the server.
- localStorage – stores data persistently in the browser.
- sessionStorage – stores data temporarily for one browser tab session.
Feature | Cookies | localStorage | sessionStorage |
|---|---|---|---|
Lifetime | Can have an expiration date or last until manually deleted | Persists indefinitely until cleared | Cleared when the tab or browser is closed |
Storage limit | ~4KB | ~5–10MB | ~5–10MB |
Accessible from JavaScript? | Yes (unless flagged HttpOnly) | Yes | Yes |
Automatically sent to server? | Yes — sent with every HTTP request to matching domain | No | No |
Primary use | Authentication, server sessions, user tracking | Client-side caching, preferences, offline data | Temporary state per tab (e.g., wizard steps) |
Shared between tabs? | Yes (same domain) | Yes (same domain) | No — per tab only |
Cookies
- Can be read by both the browser and the server.
- Often used for authentication tokens or session IDs.
- Sent automatically with requests to matching domains.
document.cookie = 'theme=dark; expires=Fri, 31 Dec 2025 23:59:59 GMT; path=/';
localStorage
- Stores data persistently — it remains even after closing the browser.
- Only accessible through JavaScript (never sent to the server).
localStorage.setItem('theme', 'dark');
console.log(localStorage.getItem('theme')); // 'dark'
sessionStorage
- Works just like localStorage but is limited to one tab.
- The data disappears when the tab is closed.
sessionStorage.setItem('tab', 'checkout');
console.log(sessionStorage.getItem('tab')); // 'checkout'
Security Notes
- Never store sensitive data (like passwords or tokens) in localStorage or sessionStorage — they are easily accessible by JavaScript.
- For secure cookies, use the
HttpOnlyandSecureflags so they can’t be accessed via JavaScript and are only sent over HTTPS.
Practical scenario
You need to persist a theme preference and an auth flag, deciding between cookies and Web Storage based on security and lifetime.
Common pitfalls
- Storing sensitive tokens in
localStorage(XSS risk). - Forgetting cookies are sent with every request.
- Assuming
sessionStoragepersists across tabs.
Cookies are better for server auth; Web Storage is client-only. Test storage limits and SameSite settings.
Think of them like hotel storage options:
- Cookies: Front desk storage — accessible by staff (server) and you (browser).
- localStorage: Your personal locker — data stays even if you leave and come back later.
- sessionStorage: Your room table — data disappears when you check out (close the tab).
- Cookies: Small, server-aware, and often used for authentication.
- localStorage: Large, persistent, and purely client-side.
- sessionStorage: Temporary, tab-specific storage.
Choose based on how long the data should live and whether the server needs to read it.
Use this as one explanation rep, then continue with the JavaScript interview questions cluster or a guided prep path.