HTML5 Browser Storage: the Past, Present and Future

I have slightly selfish reasons for writing this article; I can never remember all the client-side storage mechanisms available to HTML5 developers! I’ve possibly forgotten some now…

Why Store Data on the Client?

The main reason is practicality. JavaScript code running on the browser does not necessarily need to send all information to the server. There are several use cases:

1. You want to increase performance. You can cache data client-side so it can be retrieved without additional server requests.
2. You have a significant quantity of client-side-only data, e.g. HTML strings or widget configuration settings.
3. You want you make your application work off-line.

Let’s browse the options.

JavaScript Variables (Past, Present and Future)

The simplest choice is JavaScript variables. It may be practical to create a single global variable to store application data, e.g.

// global application storage
var appDataStore = {};

// set values
appDataStore.hello = "Hello World!";
appDataStore.info = { a:1, b:2, c:3 };

// retrieve values
console.log(appDataStore.hello);
console.log(appDataStore.info.b);

It’s also possible to store values in the page DOM as node attributes or properties. This can be useful for widget-specific values, but it’s slower and riskier than JavaScript variables; future browsers or other libraries may interpret your data in unexpected ways.

// store data in node
var mywidget = document.getElementById("mywidget");
mywidget.setAttribute("data-myvalue", "Hello World!");

// retrieve values
mywidget.textContent = mywidget.getAttribute("data-myvalue");

The advantages of JavaScript variables:

• the fastest and simplest solution
• no need to serialize or de-serialize data
• ideal for single-page applications

The disadvantages:

• very fragile — linking elsewhere, refreshing or closing the tab will wipe all data
• global variables can be overwritten and analyzed by third-party scripts.

Cookies (Past, Present and Future)

Cookies are domain-specific chunks of text data. They sound tasty, but cookie handling is awkward in JavaScript since the basic document.cookie string must be parsed, e.g.

// store cookie data
document.cookie = "hello=" + escape("Hello World") + "; path=/";

// retrieve value
cookies =
	document.cookie.split(";"),
	value = null,
	regexp = new RegExp("^\s*hello=(.*)$");
for (var c = 0; c < cookies.length && !value; c++) {
	var match = cookies[c].match(regexp);
	if (match.length == 2) value = unescape(match[1]);
}

console.log(value);

The advantages of cookies:

• a reliable method of retaining state between the client and server
• by setting an expiry date, cookie data will persist beyond page refreshes and tab closing
• cookies are supported in all modern browsers

The disadvantages:

• clunky JavaScript implementation — you will need a cookie-handling library
• values are strings only — other data must be serialized using methods such as JSON.stringify and JSON.parse
• cookie storage space is limited — do not depend on having more than 20 cookies of 4KB each
• cookies can be deleted or blocked
• cookies were unfairly labeled as a threat to internet privacy; you may need to comply with bizarre regional rules and regulations.

The flip-side of cookie client/server sharing causes the biggest technical issue. Cookie data is sent in the HTTP header of every request and response. It’s therefore appended to every HTML page, image, CSS file, JavaScript file, Ajax call, etc. If you had 50Kb of cookie data and downloaded ten 1KB images, it would result in one megabyte of additional network traffic.

window.name (Past and Present)

The window.name property is a little odd. You can set a single string value which persists between browser refreshes or linking elsewhere and clicking back, e.g.

window.name = "Hello World!";
console.log(window.name);

The advantages of window.name:

• simple to use
• data is retained on the client only and never sent to the server
• the property permits several megabytes of information
• wide browser support

The disadvantages:

• data is lost when the tab or browser is closed
• only a single string value can be stored — serialization will be necessary
• pages in other domains can read or change window.name data — never use it for sensitive information

window.name was never designed for data storage. It’s a hack and vendors could drop support at any time. For that reason, it’s best to use alternative storage options although the technique has been adopted within legacy browser shims and polyfills. See also: How to Write a Cookie-less Session Library for JavaScript

HTML5 Web SQL Database (Past)

The Web SQL Database was an initial attempt by vendors to bring SQL-based relational databases to the browser. It has been implemented in Chrome, Safari and Opera 15+, but was opposed by Mozilla and Microsoft in favor of IndexedDB. The advantages of Web SQL Database:

• designed for robust client-side data storage and access
• it uses SQL like many server side applications
• some support on Webkit/Blink desktop and mobile browsers

The disadvantages:

• SQL never seemed appropriate for client-side development
• the database schema must be defined up-front
• marginal browser support and the Webkit/Blink teams may eventually drop it
• the W3C specification was abandoned in 2010

In summary: don’t use a Web SQL Database! See also: W3C Web SQL Database Specification

HTML5 Web Storage (Present and Future)

Web Storage provides two objects with identical APIs: window.localStorage to retain persistent data and code.sessionStorage to retain session-only data which is lost when the tab is closed. Domain-specific strings are stored using name/value pairs. Unlike cookies, the storage limit is far larger (at least 5MB) and information is never transferred to the server.

// is localStorage available?
if (typeof window.localStorage != "undefined") {

	// store
	localStorage.setItem("hello", "Hello World!");

	// retrieve
	console.log(localStorage.getItem("hello"));

	// delete
	localStorage.removeItem("hello");
}

The advantages of Web Storage:

• easy to use with simple name/value pairs
• session and persistent storage options are available
• an event model is available to keep other tabs and windows synchronized
• wide support on desktop and mobile browsers including IE8+
• Web Storage polyfills are available for older browsers which fall-back to cookie and windows.name storage methods

The disadvantages:

• string values only — serialization may be necessary
• unstructured data with no transactions, indexing or searching facilties
• may exhibit poor performance on large datasets

See also:

• W3C Web Storage Specification
• An Overview of the Web Storage API
• Web Storage polyfills

HTML5 IndexedDB (Future)

IndexedDB provides a structured, transactional, high-performance NoSQL-like data store with a synchronous and asynchronous API. There’s too much to document here, but the API permits you to create databases, data stores and indexes, handle revisions, populate data using transactions, run non-blocking queries, and traverse data sets using cursors. The advantages of IndexedDB:

• designed for robust client-side data storage and access
• good support in modern desktop browsers: IE10+, Firefox 23+, Chrome 28+ and Opera 16+

The disadvantages:

• the API is very new and subject to revision
• little support in older and mobile browsers
• a large and complex API — it would be difficult and largely impractical to create a IndexedDB polyfill
• like any NoSQL store, data is unstructured which can lead to integrity issues

See also:

• W3C IndexedDB Specification
• IndexedDB reference

HTML5 File API (Future)

The HTML5 File API is being extended to support writing as well as reading sequential data on the local file system. Your domain is provided with a complete sand-boxed hierarchical file system to use as it chooses. The advantages of the HTML5 File API:

• large text and binary files can be created and stored
• performance should be good

The disadvantages:

• a very early specification which is subject to revision
• an obvious security risk unless file writing is restricted
• little support in current browsers and polyfills may be impractical
• unstructured data with no transactions, indexing or searching facilties

See also:

• W3C File API Specification

Summary

There we have it — no less than seven storage alternatives. My pragmatic recommendations at this point in time:

1. JavaScript variables will always be necessary but only use them for volatile in-memory data. Avoid DOM attributes/properties when possible.
2. Assuming it’s necessary, use cookies for retaining state between the client and server. But keep cookies small; a single token with a few characters should be enough.
3. Use HTML5 Web Storage to store data off-line or when large volumes of client-side-only information is required.
4. If you have to support older browsers such as IE6 and IE7, use a Web Storage polyfill which implements the API using cookies and window.name.
5. Keep an eye on IndexedDB; it will eventually become a viable storage mechanism when legacy browsers die out.
6. Similarly, the File API will become increasingly practical for storing unstructured data. It’s possibly the best solution for generated binary data such as images, audio, video and PDFs.

Or perhaps you have further thoughts? Comments on this article are closed. Have a question about HTML5? Why not ask it on our forums?

Frequently Asked Questions about HTML5 Browser Storage