Cookies, localStorage and sessionStorage: what to store in each one
Published on 2026-10-26 by frfrand
Differences between cookies and web storage, expiration, security, sessions, XSS and CSRF explained.
Cookies, localStorage and sessionStorage allow information related to a website to be stored, but they do not work the same way nor do they offer the same security properties. Choosing where to store session data without understanding these differences can expose information or break the functioning of an application.
What is a cookie?
A cookie is a small piece of data associated with a site that the browser can automatically send in HTTP requests that meet certain conditions.
That is why it is used to maintain sessions: the browser can attach a session identifier without each page having to ask for the password again.
Its attributes matter a lot. Secure restricts sending to secure connections in the intended contexts; HttpOnly prevents JavaScript from reading the cookie; SameSite controls part of the cross-site behavior.
One should not assume that any cookie implies advertising tracking. Some are essential for authenticating users or maintaining preferences.
What is localStorage?
It is a key-value storage available to JavaScript from the same origin, subject to browser policies. It usually preserves information even after closing the tab or the browser, although the user can delete it and the browser sets limits.
It can be used to store non-sensitive preferences, such as the visual theme of an application.
It is not an ideal place for important secrets: if an XSS vulnerability allows code to run on your page, that code can access the storage available to JavaScript.
What about sessionStorage?
It also stores values by origin, but it is associated with the session of a tab or browsing context. It is normally deleted when that page session ends.
For example, it can be useful to temporarily preserve the progress of a form in a tab. Even so, it does not constitute a guarantee of confidentiality against scripts that run within that origin.
Comparison table
| Feature | Cookie | localStorage | sessionStorage |
|---|---|---|---|
| Is it sent automatically in HTTP? | It can be sent according to its attributes | No | No |
| Can JavaScript read it? | Depends on HttpOnly and context | Yes, under origin rules | Yes, under origin rules |
| How long does it remain? | According to duration and policies | Normally until deleted or cleared | Associated with tab session |
| Common use | Sessions and preferences | Non-sensitive preferences | Temporary state of a tab |
This table simplifies some details: exact behavior depends on the browser and storage policies.
Where do I store an authentication token?
There is no universal answer. An HttpOnly cookie with correct attributes reduces exposure of the value to JavaScript, but CSRF protection must be designed when appropriate.
Storing a token in localStorage avoids its automatic sending as a cookie, but increases its exposure if a malicious script runs on the origin.
The decision depends on the architecture, threats, session duration, and how permissions are validated. Copying a solution because "everyone does it" is not enough.
Is it a good idea to store personal data?
Reduce sensitive information stored in the browser. A password field, payment data, or private documents should not persist without a real need and appropriate controls.
In addition, these mechanisms do not replace the server's database. The user can delete their local data, use another device, or browse in a private context.
A useful example
A booking website can save the preferred language in localStorage. The user session can be managed through properly configured cookies. And the current step of a form could be kept in sessionStorage for the active tab.
Confirmed bookings, payments, and permissions must be verified from the backend: you cannot trust a price simply because it appears in the visitor's storage.
What is the relationship with ArduMaker?
If you host a web application on ArduMaker, your frontend can use these mechanisms like any other website. The VPS where you run the backend does not automatically determine whether cookies or tokens are configured securely.
In one sentence: cookies, localStorage, and sessionStorage are different tools. Choose each one based on persistence, exposure to JavaScript, and actual need.
Sources: Cookies on MDN · Web Storage API · OWASP HTML5 Security.