Web Storage: A Primer

Web Storage is a relatively new approach for persistent data storage on the user’s computer (client-side).

Web Storage offers many benefits for websites/ apps. For example, Web Storage can be used to track a user’s activities across your site/app without the need for server-side scripting and databases. Web Storage can also be used to preserve some of the capabilities of your web app, even if the user suddenly goes offline, giving you the chance to provide a seamless experience despite network connectivity issues.

This article aims to present an overview and definition of Web Storage.

Web Storage vs. Cookies

The traditional way of storing data on the client-side is through the use of HTTP cookies.

There are many differences between Web Storage and cookies. Let us focus on the pragmatic differences between the two approaches for client-side data storage.

Storage Mechanism

Cookies are structured data sent to the browser by the web server as part of the server’s response to a request. Cookies can be specified via the Set-Cookie HTTP header. Whenever any request is made, the browser sends the cookies “back” to the server as part of the request’s header.

To make a long story short, a request must be made in order to update the data contained in a cookie. Also, cookies will always occupy a part of the HTTP header, whether the data has changed or not.

Web Storage, on the other hand, is created and managed completely on the client-side. Thus, among many other benefits, Web Storage avoids the involvement of the web server. This approach has many advantageous outcomes, the most obvious being that it theoretically leads to better Web performance.

Related: Web Performance articles

Also, because Web Storage can work without the need for HTTP requests/responses (beyond the initial transaction of serving up the web page), with the appropriate implementation, the data stored in the user’s browser can be updated and modified safely even if the user loses his/her network connection.

Multiple Browser Instances

Web Storage can handle situations where the user has multiple browser windows/tabs open. Data stored and/or updated in one browser window is carried over to other browser windows, as long as the other browser windows are on the same website.

Cookies, on the other hand, aren’t designed for conditions involving multiple browser windows.

Storage Size Restriction

The size limit/restriction of HTTP cookies and Web Storage varies between different web browsers. But, generally, the common best practice is to restrict the size of cookies to around 4.0 kB in order to provide good cross-browser support.

(There is a cookie testing tool which lets you test your browser’s HTTP cookie size limits.)

The W3C Web Storage specification does not recommend a default storage size restriction, leaving it up to browsers to decide. However, in practice, Web Storage comfortably exceeds the 4.0 kB limit of cookies. The generally regarded limit for Web Storage objects is around 5 MB.

That is to say, the Web Storage size limit is +124,527% bigger than that of cookies.

(There is also a Web Storage testing tool which lets you test your browser’s Web Storage size limits.)

Web Storage Types

There are two ways to store client-side data with Web Storage: sessionStorage and localStorage.

Web Storage type	Lifetime of stored data	Data structure	Data type
`sessionStorage`	Session only	Key/value pairs	String
`localStorage`	Persistent	Key/value pairs	String

sessionStorage

sessionStorage is designed to keep the client-side data only for the duration of the browsing session. In other words, data is only stored while the user is on your site.

sessionStorage, in practice, is best used for temporary data storage. For example, the user-inputted values of web form fields could be temporarily stored in a sessionStorage object for the duration of the user’s browsing session. This way, the data is available all throughout the browsing experience without the need to store the data in a server-side database system. Also, temporary storage of input data safeguards the user from having to re-enter the data, should he or she accidentally close or refresh the browser window.

localStorage

Implementation-wise, localStorage works much the same way as sessionStorage.

localStorage shares the same JavaScript methods (e.g. getItem, setItem, etc.), and it also stores data items as key/value pairs.

However, storing data as a localStorage object means the data will persist between the user’s sessions. In other words, the data will be available the next time the user visits your website.

Web Storage Browser Support

Caniuse.com reports that Web Storage has good browser support.

Web Storage Support Table

Browser	Version
Internet Explorer	IE 8 and above
Mozilla Firefox	Firefox 3.5 and above
Google Chrome	Chrome 4 and above
Apple Safari	Safari 4 and above
Opera	Opera 11.5 and above

Currently, the Web Storage specification is a W3C Candidate Recommendation. There are 5 levels of recommendations, and “Candidate Recommendation” is the third out of five levels. The existing Web Storage specification is fairly mature because it’s no longer a working draft, but at the same time, it is still not final.

Supporting old browsers that do not have Web Storage features can be done with the use of a polyfill. One such option, for localStorage support, is Store.js.

Data Privacy and Security Considerations

Web storage areas are subject to the same origin-restriction policy as cookies. This means the Web Storage areas of one website cannot be accessed by other websites. This is beneficial for data security. But it may also cause problems for websites that rely on sub-domains. In this instance, there are workarounds available, such as the open sourcepackage called Cross-Storage developed by Zendesk.

Just like with any client-side data storage mechanisms, protecting the data being stored is an important consideration. Storage of personal or sensitive data is not recommended. It is potentially easy for others who have access to the device to read local data. Consider with extra care the storage of data in situations where your users might be accessing your site in shared computing environments such colleges, libraries, work computers, and so forth.

Data integrity is also a concern. There must be safeguards against scenarios where a data storage event fails. Failure may occur when the user has disabled Web Storage, or if he/she has no more storage space available on the computer, or if his/her browser’s Web Storage size limit has been exceeded. The Web Storage specification outlines standardized errors/warnings that are outputted after failed storage events, such as the QuotaExceededError exception.

What about IndexedDB?

In terms of client-side data storage, the Indexed Database API (IndexedDB) offers many of the same benefits that you can derive from Web Storage. But IndexedDB is not a part of the Web Storage specification so it’s thus outside the scope of this guide.

However, IndexedDB is worth briefly talking about because of its shared similarities and, possibly, interconnectedness with Web Storage implementations.

Data storage with IndexedDB is slightly more complex compared to Web Storage. But, it also opens up more opportunities for complex data architectures and relationships.

With IndexedDB, the data being stored is indexed much like your favorite server-side relational database management system (RDMS), which might be MySQL, MSSQL, PostgreSQL, etc.

Related: Top Five Best Database Management Tools

In addition, you can also query IndexedDB databases in a fashion similar to server-side databases, provided you implement a querying language capable of dealing with IndexedDB databases.

Compared to IndexDB, Web Storage’s data-retrieval capabilities are basic. Web Storage only has two built-in methods for retrieving data: .getItem and .key. (In addition to the length attribute of Web Storage objects, which can output the number of items within a storage area). Thus for more sophisticated data storage, you might consider IndexedDB instead of Web Storage.