LocalStorage, SessionStorage and cookies

Web applications frequently need to remember things between page loads, between tabs, or across visits — a user's chosen theme, their favourite team, a half-completed form, an authentication session. The browser provides several client-side storage mechanisms for exactly this, and choosing correctly among them is the focus of this lesson. The three classic mechanisms are localStorage, sessionStorage, and cookies. They look superficially similar — all store data in the browser — but they differ in lifetime, capacity, scope, and crucially in whether the data is sent to the server, and those differences determine which is appropriate for a given task. localStorage and sessionStorage share an identical, very simple key-value API and differ only in lifetime: localStorage persists until explicitly cleared, surviving tab and browser closes, while sessionStorage lasts only for the lifetime of a single tab. Both are purely client-side and are never automatically sent anywhere. Cookies are older and fundamentally different in one respect: the browser attaches them to every HTTP request to the matching server automatically. This makes them the natural home for data the server needs on each request — session and authentication tokens above all — but also makes them small, capacity-limited, and a performance consideration since they travel on every request. Getting these choices right has real consequences for correctness, performance, and security. Storing an authentication token in the wrong place opens a security hole; storing large data in cookies bloats every request; storing per-tab state in localStorage causes tabs to interfere with one another. Understanding the trade-offs is what makes the choice deliberate rather than accidental.