Detailed explanation
localStorage, sessionStorage and cookies store data in the browser, but they differ in lifetime, scope and communication with servers. localStorage and sessionStorage belong to the Web Storage API and store string key–value pairs. Cookies are small pieces of state associated with a website, commonly used for login sessions and preferences. The main interview distinction is that Web Storage stays client-side unless your code explicitly sends its contents, whereas the browser automatically includes eligible cookies in HTTP requests.
localStorage is scoped to an origin: the combination of scheme, hostname and port. Pages with the same origin share it, and its data normally survives reloads and browser restarts until removed by code, the user or browser policies. sessionStorage is scoped to both an origin and a browser tab's page session. It survives reloads but normally disappears when that tab closes. For example, localStorage.setItem('theme', 'dark') saves a persistent preference, while sessionStorage.setItem('step', '2') saves temporary progress. Both APIs are synchronous, so large reads and writes can block JavaScript execution. Their quotas are browser-dependent, commonly around 5 MiB per storage area per origin, rather than a guaranteed universal limit.
Web Storage accepts strings, so objects usually require JSON.stringify() before saving and JSON.parse() after retrieval. getItem() returns null for a missing key; JSON.parse(localStorage.getItem('user') ?? 'null') therefore handles a missing user entry, but malformed stored JSON can still throw. Storage operations can also fail because of quota limits or browser restrictions. Avoid treating browser storage as a trusted database or putting sensitive credentials there: JavaScript running on the origin, including injected scripts, can access it.
Cookies typically hold only about 4 KB each and can be created through the server's Set-Cookie response header or JavaScript when permitted. Max-Age or Expires controls persistence; without either, a cookie is generally a session cookie, though browser session restoration can preserve it. Domain, Path, Secure and SameSite rules influence when cookies are sent. HttpOnly prevents JavaScript from reading a cookie, while Secure restricts transmission to HTTPS. Interviewers expect you to choose storage based on lifetime, server access and security—not simply capacity.
Key points to remember
- localStorage is shared within an origin and normally persists across browser restarts.
- sessionStorage is origin- and tab-scoped, survives reloads and normally clears when the tab closes.
- Both Web Storage APIs synchronously store strings; objects need serialisation, and quotas vary by browser.
- Cookies are roughly 4 KB each and are automatically sent with eligible requests, subject to cookie and browser rules.
- Use persistent storage for preferences, session storage for temporary tab state, and appropriately secured cookies for server-managed sessions.
Common mistakes candidates make
- Saying sessionStorage clears on refresh or that localStorage can never be cleared by the browser.
- Saving an object directly without JSON.stringify(), or assuming JSON.parse() cannot fail.
- Claiming cookies go with every request regardless of destination, or assuming browser storage is safe for sensitive credentials.
Likely follow-up questions
How do you remove data from Web Storage?
Use removeItem('key') to delete one entry and clear() to remove every entry in the selected storage area. For example, localStorage.removeItem('theme') removes only the stored theme preference.
Is an HttpOnly cookie completely safe from XSS and CSRF?
HttpOnly prevents JavaScript from reading the cookie, but injected scripts may still perform authenticated actions. Use XSS prevention measures and appropriate CSRF defences, such as SameSite settings and CSRF tokens where needed.
Can different tabs share stored data?
Same-origin tabs share localStorage, and changes can trigger a storage event in other documents sharing that storage area. sessionStorage is separate per tab, although a newly opened tab with an opener can initially receive a copy that subsequently remains independent.
Interview tip: Compare lifetime, scope, capacity and server transmission first, then give a practical use case and one security caution.