localStorage and sessionStorage: what the browser remembers about the page

Useful to know

A web page can retain a preference in the browser so that the visitor does not select it every time they open. One of the mechanisms is localStorage. Its data is associated with the origin of the document and is usually retained between browser sessions, without its own automatic expiration date. [1] It is a convenient basis for selecting a view or other local setting. However, it is important to understand what kind of memory is used before an expectation of reliable storage is built on it.

SessionStorage is organized around the session of the specific section and the corresponding origin. Reloading the page does not automatically terminate this session until the tab or window closes. [2] Therefore, "session" does not necessarily mean "until the first press of Refresh". The difference matters for temporary data from the interface, which must survive one update of the document, but is not expected to remain as a long-term setting for the next independent visit to the site.

LocalStorage stores keys and values as strings. HTTP and HTTPS addresses have separate storage spaces, and browser policies may prohibit retention. In private viewing, the behavior also has features. [1] This means that the same visual site should not assume the presence of the old setting after a protocol change. The app must be able to start with a reasonable default value when expected local content is missing or access to it is denied.

Opening a new tab creates a separate side session. In the presence of opener, the initial sessionStorage may be a copy of the opening window, but then the changes remain independent. [2] This detail explains why the simple "any new tab is always completely empty" rule is overly explicit. It is more accurate to consider the specific way of opening. Then you can check what state the interface expects and whether two simultaneously open pages should influence each other.

Let's imagine a filter in a catalog. For a permanent preferred view, one solution can be used, and for a temporary step in a current tab, another. This is a design example, not a mandatory recipe. The first question is how long the value should live. The following are the questions whether it is needed on another device and whether it is reliable enough for it to stand only in this browser. The local setting is not automatically equivalent to a saved profile in the server base.

When checking, it is useful to try updating, a new tab, closing, and a new visit. This is how you see if the actual behavior matches the promise in the interface. Data read from the local repository should be processed as input, which may be missing or unexpected. The proper choice between the two mechanisms begins with the life and purpose of value. Knowing the names is just the first step; more important is what exactly the app promises to remember about the person across the street.