Cookies, localStorage, and sessionStorage: How Websites Remember You

A website can remember your language preference, keep a shopping cart available, or recognize that you are signed in. That does not mean every piece of information belongs in the same storage system. Cookies, localStorage, and sessionStorage all keep data in or around the browser, but they differ in who receives the data, how long it lasts, and what happens when a page or tab changes.

The useful beginner question is not “Which one is best?” It is: who needs to read this value, for how long, and what would happen if JavaScript or another request exposed it? Cookies are designed to participate in HTTP requests. Web Storage is designed for client-side key-value data. Neither should be treated as a password vault.

The Browser Has More Than One Memory

The right choice also depends on where the application’s source of truth lives. Browser storage can improve continuity and speed, but it should not become the authority for permissions, billing, or other decisions that must remain enforceable on the server.

Before comparing the APIs, it helps to connect them to the request cycle. When a browser visits a page, it sends an HTTP request and receives a response. As explained in Vandutz’s walkthrough of how websites work, the server may return HTML, headers, scripts, stylesheets, and other resources. State is the information that lets later interactions have some relationship to earlier ones.

HTTP itself treats requests as independent exchanges. A server does not automatically know that two requests came from the same browser just because they happened a few seconds apart. Storage mechanisms provide ways to carry preferences, identifiers, or temporary application state across those exchanges. The mechanism you choose changes the direction of the communication.

Cookies Travel With the HTTP Conversation

A cookie is a small value that a server asks the browser to store. The browser can later send that value back to the relevant server in a Cookie request header. MDN describes session management, personalization, and tracking as common uses for cookies, but the defining technical feature is their relationship with HTTP: they can be included automatically in requests that match their scope.

A response might contain a header such as:

Set-Cookie: language=en-US; Max-Age=2592000; Path=/; Secure; SameSite=Lax

On a later request, the browser may send:

Cookie: language=en-US

The browser decides whether to include the cookie based on attributes such as domain, path, expiration, security, and cross-site rules. The MDN cookie guide explains that Secure limits transmission to HTTPS, HttpOnly prevents JavaScript from reading the cookie, and SameSite controls when the cookie is sent with cross-site requests.

That automatic behavior is useful when the server needs the value. It is also the reason cookies should not be filled with unnecessary data. A cookie sent with many requests adds bytes to the exchange, and a sensitive session cookie must be configured deliberately rather than treated as an ordinary preference.

localStorage Stays on the Client

localStorage is part of the Web Storage API. It stores string key-value pairs for a document origin, such as a particular HTTPS scheme, hostname, and port. The data normally remains available after the browser is closed and reopened, which makes it suitable for preferences that should survive multiple visits.

localStorage.setItem("theme", "dark");

const savedTheme = localStorage.getItem("theme");

localStorage.removeItem("theme");

The browser does not automatically attach this value to every HTTP request. Your JavaScript has to read it and decide what to do. That makes localStorage convenient for a theme, dismissed tutorial notice, draft form value, or other non-sensitive client-side preference. It also means the server will not know about the value unless your code explicitly sends it.

Persistence is a feature, not a guarantee of safety. Any JavaScript that runs in the same origin can generally access the storage area. If an application has a cross-site scripting vulnerability, code injected into that origin may be able to read values stored there. This is why authentication tokens, session IDs, refresh tokens, and credentials should not be placed in localStorage.

sessionStorage Belongs to a Page Session

sessionStorage uses a similar interface but a different lifetime and partitioning model. MDN describes it as separated by origin and browsing tab. A value stored in one tab is not automatically the same value available in another tab, and the data is cleared when the page session ends.

sessionStorage.setItem("checkoutStep", "shipping");

const step = sessionStorage.getItem("checkoutStep");

sessionStorage.removeItem("checkoutStep");

This makes it a reasonable fit for temporary state that should survive a reload in the same tab but should not become a long-term preference. A multi-step form, a temporary comparison list, or a one-tab workflow may fit this model. It is still accessible to JavaScript, so its shorter lifetime does not make it appropriate for secrets.

Origin Explains Why Storage Does Not Follow Every Link

Web Storage is partitioned by origin. In practical terms, https://example.com and http://example.com do not share the same localStorage area, and a different port also creates a different origin. A page on app.example.com does not automatically receive the storage of www.example.com.

This boundary is useful because one site should not be able to casually read another site’s client-side data. It can also surprise beginners who move a project from local development to production. A value saved while testing on http://localhost:3000 is not the same value available on a deployed HTTPS domain.

Cookies use domain and path attributes to define where they are sent, while Web Storage follows the origin model. These are related ideas but not interchangeable ones. If you need to understand the secure protocol that sits underneath the exchange, review the Vandutz guide to HTTP and HTTPS.

Persistence Is Not the Same as Security

A common mistake is to treat “stored in the browser” as a security decision. It is only a storage decision. A user can inspect, clear, copy, or modify browser storage. A script running in the origin may also read Web Storage. The application must validate important values on the server instead of trusting a client-side flag such as isAdmin=true.

For authenticated sessions, the security model is different. OWASP’s Session Management Cheat Sheet recommends protecting session identifiers with controls such as HTTPS, the Secure attribute, and HttpOnly. It also discusses SameSite, session expiration, and the danger of predictable or exposed session identifiers.

There is a useful division of responsibility here. The browser may remember a visual preference, but the server must decide whether a user is authorized to view private data. If JavaScript reads a preference and sends it to the server, the server should still validate the value. Client-side storage can improve experience; it should not replace access control.

Do Not Confuse Storage With a Database

All three mechanisms can look like tiny databases because they store named values, but their constraints are different. Cookies are small and participate in requests. Web Storage uses synchronous JavaScript methods, so reading or writing a large amount of data can block other browser work. For larger, structured, or asynchronous client-side data, IndexedDB or a server-side database may be more suitable.

Start with the smallest mechanism that matches the job. A theme preference does not need an authenticated server session. A server-side session should not be simulated with a value that JavaScript can freely edit. A large offline dataset should not be squeezed into a collection of cookie strings.

A Practical Decision Sequence

1. Does the server need the value automatically? If yes, a cookie may be appropriate, because it can travel with matching HTTP requests. Keep it small and configure its attributes.
2. Should the value survive a browser restart? If it is a non-sensitive client preference, localStorage may fit. Document how the value is cleared and what happens when storage is unavailable.
3. Should the value last only in the current tab? Consider sessionStorage for temporary workflow state, but remember that JavaScript can still read it.
4. Would exposure change permissions or reveal a credential? Do not put the value in Web Storage. Use a server-side design and a properly protected session mechanism instead.
5. Could the value grow or require complex queries? Move beyond synchronous Web Storage and evaluate IndexedDB or server-side persistence.

Inspect the Storage You Already Have

You do not need to guess which mechanism a page uses. Open the browser’s developer tools and inspect the Application or Storage panel. Look at Cookies, Local Storage, and Session Storage separately. For each entry, note its name, value shape, expiration, domain, path, and whether it is marked secure or HTTP-only. Do not copy real session values into screenshots, tutorials, or public issue reports.

Then open the Network panel and reload the page. Check whether a cookie appears in request headers, whether a response sets a new cookie, and whether JavaScript requests contain values read from Web Storage. This connects the storage panel to the request cycle instead of treating the browser as a black box.

When you learn the difference between cookies, localStorage, and sessionStorage, you gain a durable design habit: choose storage by communication path, lifetime, scope, and risk. Remember preferences on the client, send small server-needed state through carefully configured cookies, and keep authentication decisions on the server where users cannot simply edit the answer.

Explore the browser layer behind these storage decisions

Alex Carter

Alex Carter is the editorial name behind Vandutz Academy, a programming blog for beginners. Alex reviews and tests the examples and explanations published on the site, with a focus on making Python, JavaScript, web development, and developer tools easier to understand.