Introduction to HTML5 Web Storage

7 min. read
William Craig

CEO & Co-Founder
President of WebFX. Bill has over 25 years of experience in the Internet marketing industry specializing in SEO, UX, information architecture, marketing automation and more. William’s background in scientific computing and education from Shippensburg and MIT provided the foundation for MarketingCloudFX and other key research and development projects at WebFX.

Web Storage is a new HTML5 API offering important benefits over traditional cookies. Although the specification is still in W3C draft status, all major browsers support it already. This means you can start using the API’s sessionStorage and localStorage objects (we will discuss these later on) and enjoy their benefits.

The Limitations of Cookies

First, there were cookies. They have been a huge driving factor for the Web since the early days. In both a good and a bad way.

For example, cookies allow us to login automatically to sites we use frequently, such as Gmail and Facebook. On the other hand, with cookies, our search and browsing history can be tracked and our privacy is a concern. Another problem with cookies is that they have data-capacity limitations.

The data storage limit of cookies in many web browsers is about 4 KB per cookie, based on a deprecated 1997 specification recommending a minimum of 4096 bytes per cookie. Although most browsers allow 30 to 50 cookies, so if you exceed the 4 KB limit of one cookie you could create another one, this is still a real limitation. This is why developers usually only store user and/or session identifiers in cookies, and then use server-side databases to store and get the rest of the user data.

Additionally, an often-overlooked side effect of cookies is that they are always sent with every HTTP request (usually even for images) resulting in more data being sent over the wire.

Moving Forward with Web Storage

Web Storage picks up where cookies left off. The strength of Web Storage is in at least two things.

First, ease of use for web developers: It has a simple API to get and set key/value pairs (we will get more into this below). Secondly, the amount of space it provides: the specs default the disk space quota decision to the user agent (i.e. the web browser developers) and most of them offer no less than 5 or 10 MB to be stored per domain.

This means we can store more than just basic user/session info on the client-side: user preference settings, localization data, temporary offline storage for batching server writes and much more. The data being stored can be accessed using JavaScript, which gives you the ability to leverage client-side scripting to do many things that have traditionally involved server-side programming and relational databases.

Session Storage and Local Storage

It is important to know that there are two types of Web Storage objects: sessionStorage and localStorage.

sessionStorage is only available within the browser tab or window session. It’s designed to store data in a single web page session. localStorage is kept even between browser sessions.

This means data is still available when the browser is closed and reopened, and also instantly between tabs and windows. Web Storage data is, in both cases, not available between different browsers. For example, storage objects created in Firefox cannot be accessed in Internet Explorer, exactly like cookies.

Where to Use Web Storage

Some examples of implementation scenarios include storing the data for an online to-do list (then pushing to the server in intervals instead of in real-time) or saving products that the user places in his shopping cart. The data can be made available between page requests, multiple browser tabs, and also between browser sessions using localStorage. Your apps can actually be used offline completely using localStorage.

Data can then be sent and stored server-side when the user is online again. From another perspective, Web Storage can be a great performance win when some static data is stored on the client to minimize the number of subsequent requests. Even images can be stored in strings using Base64 encoding.

For the examples mentioned above, it makes sense to use localStorage. You may be wondering, then, when you should opt for sessionStorage. In some cases, you simply want to get rid of the data as soon as the window is closed.

Or, perhaps, you don’t want the application to interfere with the same application that’s open in another window (e.g. when running two instances of a Scrabble game or running multiple unit tests simultaneously, you don’t want data to collide). These scenarios are served best with sessionStorage.

Using the Web Storage API

It’s really simple. It’s probably best just to show it:

sessionStorage.setItem('myKey', 'myValue'); var myVar = sessionStorage.getItem('myKey'); localStorage.setItem('myKey', 'myValue'); var myVar = localStorage.getItem('myKey');

Note that the interface for creating sessionStorage and localStorage is identical and that they are global objects. You can use the .setItem method to set the key and its value, and then .getItem to retrieve the value of a specific key.

Note that we can only store strings, which is a significant drawback. However, to get around this, we can store and retrieve string representations of JSON objects by using the JSON.stringify() method to store a string, and JSON.parse() to create the original object from that string.

Web Storage Events

Whenever we store data in localStorage, the storage event is fired in other browser windows/tabs.

What is so great about that? This event can be used to overcome that so-called race conditions between browser windows/tabs: If the user has the same site open in different tabs, this event can be used to synchronize the data. (This was actually quite an issue with cookies.) 0182 02 localstorage event The storage event is only fired when the new value is not the same as the old value.

The storage event contains the key, oldValue and newValue properties of data that has changed, which you can access in code. Example code:

window.addEventListener('storage', function(event) { console.log('The value for ' + event.key + ' was changed from' + event.oldValue + ' to ' + event.newValue); }, false);

Above, we create an event listener on the window object for the storage event. When the event happens, a function that logs the key, oldValue and newValue to your console (e.g.

Firebug or Google Chrome Developer Tools) is executed.

Browser Support for Web Storage

You are encouraged to start using this API today. Web Storage is implemented in IE8 and in all modern browsers (i.e.

starting from Firefox 3.5, Safari 4, Google Chrome 4, and Opera 10.50). The storage event was added later, but is available in at least Firefox 5, Safari 5, Chrome 12, Opera 10.5 and reportedly in IE9.

Security Concerns

Please be aware that using Web Storage is really not more secure than cookies. With greater power, comes greater responsibility. SSL does a great deal of resolving security issues.

(SSL means the client and server communicate only encrypted data). This is why you see more and more websites using the more secure https protocol. In any case, do not store sensitive data (like passwords and credit card numbers) on the client-side, nor send this kind of data to the client.

Final Notes

Web Storage is sometimes referred to as DOM Storage, this is the same thing. The latter is derived from the fact that the data is actually stored in JavaScript’s window object (i.e. window.localStorage and window.sessionStorage).

And last but not least, keep in mind that Web Storage, just like cookies, can be turned off by the user. So you always need to implement a fallback mechanism in case window.sessionStorage or window.localStorage is not available.