Web Storage API - Web APIs | MDN (original) (raw)

The Web Storage API provides mechanisms by which browsers can store key/value pairs, in a much more intuitive fashion than using cookies.

Concepts and usage

The two mechanisms within Web Storage are as follows:

• sessionStorage maintains a separate storage area for each given origin that's available for the duration of the page session (as long as the browser tab is open, including page reloads and restores).
• localStorage does the same thing, but persists even when the browser is closed and reopened.

These mechanisms are available via the Window.sessionStorage and Window.localStorage properties. Invoking one of these will return an instance of a Storage object, through which data items can be set, retrieved and removed. A different storage object is used for the sessionStorage and localStorage for each origin — they function and are controlled separately.

To learn about the amount of storage available using the APIs, and what happens when storage limits are exceeded, see Storage quotas and eviction criteria.

Both sessionStorage and localStorage in Web Storage are synchronous in nature. This means that when data is set, retrieved, or removed from these storage mechanisms, the operations are performed synchronously, blocking the execution of other JavaScript code until the operation is completed. This synchronous behavior can potentially affect the performance of the web application, especially if there is a large amount of data being stored or retrieved.

Developers should be cautious when performing operations on sessionStorage or localStorage that involve a significant amount of data or computationally intensive tasks. It is important to optimize code and minimize synchronous operations to prevent blocking the user interface and causing delays in the application's responsiveness.

Asynchronous alternatives, such as IndexedDB, may be more suitable for scenarios where performance is a concern or when dealing with larger datasets. These alternatives allow for non-blocking operations, enabling smoother user experiences and better performance in web applications.

Determining storage access by a third party

Each origin has its own storage — this is true for both web storage and shared storage. However, access of third-party (i.e., embedded) code to shared storage depends on its browsing context. The context in which a third-party code from another origin runs determines the storage access of the third-party code.

Third-party code can be added to another site by injecting it with a