How Much Data Can You Store?
The APIs also differ in the quantity of data they can store, so even if you are storing strings, your API choice is affected by how much string data you need to store.
As mentioned earlier when we were discussing the limitations of cookies, they can only store up to 4KB each (~4000 ASCII characters), and the specification recommends that browsers support a minimum of 20 per domain and a 300 total. The
localStorage quota varies, with some browsers supporting 2MB per domain, some seemingly unlimited, and most averaging around 5MB.
File API specifications don't yet give recommendations for how much browsers should give to websites, so Chrome is currently experimenting with a unified quota API for those APIs. With their quota system, there are two types of storage temporary and permanant. Any data in temporary storage can be evicted by the browser whenever it feels the need. Data in permanent storage will only be removed when the website or user requests it. For temporary storage, a website can use up to 20% of the total available temporary storage space, but for any permanent storage, the website must explicitly ask the user for the permission to use that space, and then can request however much space is available.
With all of these APIs, you can never safely assume that you can store everything. It's the user's computer that you're storing data on, not your own server, and it's ultimately up to the users to decide what to do with their hard drive space.
This table summarizes the storage restrictions:
|Cookies||4KB each, 20 per domain min|
|IndexedDB||Temporary: up to 20% of available space per app. Permanent: Can request up to 100% of available space.|
|File API||See IndedexedDB|
How Do You Query Data?
Once you've stored the data, you need a way to get it back out. With most of the APIs cookies,
File API your "query" is just a key name. It's basic, but if you have well-named keys, that may be enough for you. With
IndexedDB, you can create indexes on properties and cursors with key ranges (
This table summarizes the query capabilities:
How Well Does It Perform?
For all of these APIs to store data persistently across browser restarts, the browser must write the data to disk and read it from disk and that makes the performance of these APIs subject to the duration of read/write operations on the hard drive. Besides the read/write overhead for all of them, there are other performance characteristics for each technique.
As mentioned earlier, cookies are added to HTTP requests, so they affect the actual size of HTTP requests over the wire and the subsequent loading time of a webpage.
localStorage is a synchronous API, so when your code attempts to set or get an item, it blocks the rest of the code from executing until the operation is done. In addition, if you are using
localStorage to store objects by serializing them into JSON strings, your code is slowed down by how long it takes to do in-browser serialization.
File APIs are both asynchronous APIs, which makes code more complex, but can also make for a more performant website because the read/write operations aren't blocking the execution of the rest of your code.
In figuring out how performance matters to your particular use case, think about how much data you're planning to store/retrieve, how often you're planning to store and retrieve that data, and how complex that data is.
This table summarizes performance considerations:
|Cookies||Bigger HTTP requests, Read/writes to disk|
|localStorage||Blocking read/writes, Serialization, Read/writes to disk|
|IndexedDB||Async read/writes, Read/writes to disk|
|File API||Async read/writes, Read/writes to disk|
What Browsers Does It Work In?
In an ideal world, you would pick the best API for the job based on just the previous considerations, but since we're dealing with emerging API standards here, you need to seriously consider which browsers support which API, and what browsers you need to support for your website and ultimately, this may be the only question that matters at this point in time.
The HTML5 storage options have a wide range of browser support, as there's been a lot of disagreement in the standards world about what a client-side storage API should look like. The
localStorage API was the simplest and least controversial of the APIs, and so it was the first to be implemented. It's now supported in all "modern browsers," including IE8. The
File APIs are growing in acceptance among browser vendors and I hope to see significantly more support for them over the next year. At the time of writing, however, the
IndexedDB is supported only in FireFox 4+ and Chrome 11+. The
File API is only supported in Chrome.
Figure 1 summarizes the current support. For the latest, check caniuse.com.
Which API to Use?
If you're in the rare (quite fortunate) situation of having to develop only for one browser (like making a Chrome extension or an internal tool), you could consider using the
File API or
IndexedDB API. However, most Web developers are trying to target multiple browsers and given the browser support situation, the only practical cross-platform HTML5 data storage option is the
It certainly has its drawbacks notably, the blocking synchronous methods and the potentially slow serialization but as long as you stay aware of those shortcomings when working with it, you can use this simple storage API for improving your websites.
Stay tuned for part 2 of this series, in which I’ll dive deeper into
localStorage and present different ways it can enhance your sites. In the meantime, if you want more information on local storage, you can watch and listen to my 30-minute webinar on client-side storage for Dr. Dobb’s on this topic.