JavaScript Web Storage

The web, by its original design, has amnesia. The HTTP protocol is **stateless**, meaning each request from a user to a server is treated as a completely independent event. The server doesn't inherently remember you from one click to the next. To build modern, interactive applications that feel personal—like remembering a login, a theme preference, or a shopping cart—we need a way to store data on the user's device. This is where **client-side storage** comes in.

The Web Storage API: `localStorage` and `sessionStorage`

Modern browsers provide a `Window.Storage` API, which gives us two powerful, easy-to-use mechanisms: `localStorage` and `sessionStorage`. Both store data as **key-value pairs** and, crucially, **they only store strings**. To store objects or arrays, you must first serialize them with JSON.stringify() and deserialize them with JSON.parse().

1. `localStorage`: The Digital Vault

`localStorage` is for **persistent** data. Data stored here has **no expiration date**. It will remain on the user's computer until it is explicitly cleared by the user (by clearing their browser cache) or by your web application. It's available across all tabs and windows of the same origin.

• **Capacity:** Around 5-10MB (browser-dependent).
• **Persistence:** Permanent, until manually cleared.
• **Scope:** All tabs/windows from the same origin.
• **Use Cases:** User preferences (like 'dark-mode'), remembering a user's name, or other non-sensitive data you want to persist between visits.

// Store an object
const userPrefs = { theme: 'dark', notifications: false };
localStorage.setItem('preferences', JSON.stringify(userPrefs));

// Retrieve and parse the object
const savedPrefs = JSON.parse(localStorage.getItem('preferences'));
console.log(savedPrefs.theme); // "dark"

// Remove the item
localStorage.removeItem('preferences');

// Clear all items for this origin
localStorage.clear();

2. `sessionStorage`: The Temporary Scratchpad

`sessionStorage` is for **session-only** data. It has the exact same API as `localStorage` (`setItem`, `getItem`, etc.), but with one critical difference: its data is cleared the moment the **page session ends**. A page session lasts as long as the browser tab is open. When the user closes the tab, the data is gone.

• **Capacity:** Around 5-10MB (browser-dependent).
• **Persistence:** For the lifetime of the tab.
• **Scope:** Only the tab that created it.
• **Use Cases:** Storing data for a multi-step form (so the user doesn't lose progress on refresh), temporary application state, or items in a shopping cart before checkout.

`Cookies`: The Server's Messenger

Cookies are the "old guard" of client-side storage. They are tiny bits of data (max ~4KB) that a server sends to the browser, which the browser then stores. The key difference is that cookies are **sent back to the server with every subsequent HTTP request** to that same domain. This is what makes them ideal for authentication, but also their biggest drawback (it adds overhead).

While you can set cookies with JavaScript (`document.cookie = "..."`), they are often set by the server via an HTTP header. They have powerful attributes:

• `HttpOnly`: **The most important security attribute.** When set, the cookie is inaccessible to client-side JavaScript (`document.cookie` won't see it). This makes it **immune to XSS attacks** where a hacker tries to steal the cookie.
• `Secure`: Ensures the cookie is only sent over HTTPS, preventing it from being intercepted on insecure (HTTP) connections.
• `SameSite` (`Strict`, `Lax`, `None`): A powerful defense against **CSRF (Cross-Site Request Forgery)** attacks. It controls whether a cookie is sent with requests initiated from other domains.
• `Max-Age` / `Expires`: Sets the cookie's expiration date. If omitted, it becomes a "session cookie" and is cleared when the browser closes.

The Great Debate: `localStorage` vs. `HttpOnly` Cookies for Auth

A common task is storing an authentication token (like a JWT) after a user logs in. Where should it go?

Key Takeaway: Use `localStorage` for non-sensitive user preferences. Use `sessionStorage` for temporary, in-tab data. Use **`HttpOnly`, `Secure`, `SameSite` cookies** for all sensitive data, especially authentication tokens.