This article is excerpted from HTML5 Developer's Cookbook and reprinted with permission of publisher Pearson/Addison-Wesley Professional.
The persistence of information in the visitor's browser has historically been limited to keys and values in cookies. Cookie storage is limited in size and structure, and cookies are passed with each request to their corresponding websites, creating unnecessary overhead. Certain sets of data could improve the user experience if cookies could be stored and retrieved locally, instead of being retrieved by web servers each time they are used.
In HTML5, two client-side storage facilities have been added: web storage, which includes session and local storage, and database storage. In this article, you will learn about these new client-side storage options and work through some recipes to get you started with storing data locally in the browser.
Client-side storage overview
To start talking about the new storage APIs, let's first look at what we previously had available in browsers to store information locally. Typically, to store information that could be retrieved at a later time in a visitor's browser, you had to create a cookie. Information stored may have included user preferences, form information, user keys, or the like. However, the storage of cookies is limited to approximately 4KB, contains only simple key/value pairs, and increases overhead by sending the cookie with each request to the server.
The session and local web storage options provided in HTML5 are similar to cookies in that the structure is in key/value format, in which string values can be assigned to string-based keys. A value can be accessed in the session or local storage by asking for the appropriate key in the storage object.
The difference between the session and local options is simply the scope of the object in the visitor's session. In session storage, the data is stored only for that particular session with the website. Once the session has ended, through closing the window or tab in the browser, the storage will be removed. When the user returns, the session storage will be empty.
If, instead, you want the data to be available across sessions, whether at the same time in another window or a new session at a later date, then you can use the local storage, which is persisted even after closing the current session.
Key/value pairs limit storing more complex information (or at least make it difficult). Thus, a third type of storage has been added to provide data storage like you would normally use on the server side: database storage. Database storage leverages a SQLite database or IndexedDB and allows you to store more complex data objects, as you will see later.
Table 1: HTML5 client storage
types and properties| Storage | Format | Scope | Persistence |
|---|---|---|---|
| Session | Key/value | Session only | Session only |
| Local | Key/value | Across sessions | Across sessions |
| Database | Structured | Across sessions | Across sessions |
Like local storage, database storage persists across sessions. Which storage mechanism you use in your website or application depends on the type of information you need to store, the scope of the data, and how long you need the data to be persisted. Table 1 provides a quick way to determine the appropriate storage type.
Data security
When we discuss data storage, we must also discuss security. Like storing information in a server database of a web application, similar security guidelines should be applied to database storage on the client side. This is especially true since unlike a server where you may have control over the firewalls, users, passwords, and other security features, a visitor's browser is outside the immediate network. This makes it that much more important to be vigilant about what is stored in the client browser and how it is stored.
Encryption may be a consideration depending on the data you are storing, but if you are considering encryption of the data, you may want to reconsider storing it in the first place.
The storage options in HTML5 employ origin-based security by limiting access to session, local, and database client-side storage to pages that originate from the same domain from which the storage was created. In this manner, pages from other sites or applications cannot access the data. However, the origin security implementation uses the page's origin as the determining factor for access to the session and local storage lists of key/value pairs. Because of this, there is the potential for storage to be exposed to embedded scripts. This makes knowing the actions that the external files you use in your pages that much more important.
Note: Data you store using the local, session, or database objects is limited to the specific browser that is being used by the visitor at the time. If the user returns to your site or application using a different browser or a different computer, then the storage will not be accessible. Data that you would like accessible anywhere will still need to be stored on your database server or in the cloud.
Table 2: HTML5 client storage
browser availability| Browser | Versions |
|---|---|
| Android | 2.1+ |
| Chrome | 10.0+ |
| Firefox | 10.6+ |
| Internet Explorer | 8.0+ |
| iOS Safari | 3.2+ |
| Opera | 10.6+ |
| Safari | 4.0+ |
Client-side storage is being adopted rapidly by the different browser platforms, and Chrome is the leader in this support. There is still debate about the implementation of the best database storage mechanism by the different browsers, but Table 2 lists the current support of the client-side storage objects by various browsers.
Keys and values: sessionStorage and localStorage
The session storage and local storage objects are similar in their implementations and differ only in the scope and persistence of the data that is written, as shown in Table 1.
The browser provides a built-in storage interface for each storage type, sessionStorage and localStorage, and each uses a list of key/value pairs to store the data. You can set a value to a key and then retrieve the value by asking for the key.