Web Storage and cookies from JavaScript

localStorage persists data with no expiration at all — it survives closing the tab, closing the browser entirely, and restarting the computer, remaining until explicitly removed via code or the user manually clearing site data. Every value is stored as a string — localStorage.setItem("user", someObject) silently stores the string "[object Object]", not the actual object, which is why storing structured data requires JSON.stringify() on the way in and JSON.parse() on the way out.

sessionStorage shares localStorage's exact API (setItem, getItem, removeItem) but with genuinely different persistence: it survives a page reload within the same tab, but is cleared the moment that specific tab closes, and — critically — each tab gets its own independent sessionStorage, even for the same site opened in two different tabs simultaneously. This makes it the right choice for data that should genuinely be scoped to one browsing session in one tab (an in-progress, unsaved form draft) rather than something meant to persist and be shared across every tab and every future visit.

Cookies are fundamentally different from localStorage/sessionStorage in one critical way: they're automatically included in every HTTP request to their domain (recall this platform's Web Security domain's CSRF lesson, which depends entirely on exactly this automatic-attachment behavior) — genuinely useful for session tokens the server needs to read on every request, something localStorage structurally can't do, since its contents are never sent over the network at all. The JavaScript API for cookies (document.cookie) is real, but genuinely awkward: setting one cookie means writing a whole formatted string, and reading returns every cookie concatenated into one string that has to be manually parsed.

localStorage and sessionStorage both have a real, practical storage limit — typically around 5–10MB per origin, varying by browser — small enough that storing anything resembling real application data (not just settings and small cached values) will genuinely hit the limit and throw a QuotaExceededError. This is worth knowing explicitly: localStorage is the right tool for small, simple values (preferences, feature flags, small cached API responses) and structurally the wrong tool for anything approaching "a real, growing dataset" — that's what IndexedDB (a genuine, more capable browser database, beyond this lesson's scope) or the actual server-side database exist for.

Every mechanism this lesson covers is readable by JavaScript running on the page — which means a successful XSS attack (covered directly in this platform's Web Security domain) can read anything stored in localStorage, sessionStorage, or a non-HttpOnly cookie and send it to an attacker. A real secret that the server alone needs belongs in an HttpOnly cookie specifically (which JavaScript genuinely cannot read at all, closing exactly this exposure) or, for true API secrets, kept entirely server-side and never sent to the browser in the first place.