HTML5 – Offline Capabilities Using the Cache Manifest

David Pitt HTML5, Technology Snapshot Leave a Comment

One of the most interesting features of the HTML5 specification is the capability for web applications to perform while offline (i.e. without internet connectivity). Most browsers implement a caching mechanism that stores downloaded resources to a local drive, which is done as resources are encountered. While this does help with performance, as resources are only cached as they are encountered, not all resources may be cached. So, potentially, if connectivity is lost then the site is not fully functional.

Introducing the the Cache Manifest. A manifest file contains caching directives for what to cache, what to not cache, and instructions on what to do when a web resource is not available. This text file defined by the web application indicating to an HTML5 complaint browser resources to cache in “application cache.” This manifest file is referenced by an HTML manifest attribute. An example is shown below:

<html lang="en-us" manifest="example.appcache" >

Explicitly specifying the browser to cache specific HTML, Javascript, and CSS files is done by defining these elements under a CACHE directive in the manifest file. This file contains an identification directive along with a CACHE directive, followed by specific resources to cache. An example is shown below:

CACHE MANIFEST # 2012-9-1:24
# Explicitly cached 'master entries

Comments can be added to the file using # tag. Also, comments can be used to invoke a cache refresh from the browser; when contents change in this file, the browser will re-download entries. It is also worth noting that this downloading is asynchronous.

Resources that always require connectivity (and therefore will bypass the application cache) can be specified under the NETWORK: directive, as shown below.


Another nice feature is the ability to provide an alternative HTML file for resources that are inaccessible from the server.  A FALLBACK: directive can be defined that will associate certain resource(s) with an HTML page for display when a browser can’t access a particular resource. The example below shows a FALLBACK: entry for any inaccessible HTML resource. Notice, wildcards are allowed in the FALLBACK: and NETWORK: directives.

/*.html  /offline.html

The application cache can also be controlled via a Javascript API. The status of an application cache can be checked by testing state on the:

var appCache = window.applicationCache;

switch (appCache.status) {
  case appCache.UNCACHED: // UNCACHED == 0
    return 'UNCACHED';
  case appCache.IDLE: // IDLE == 1
    return 'IDLE';
  case appCache.CHECKING: // CHECKING == 2
    return 'CHECKING';
  case appCache.DOWNLOADING: // DOWNLOADING == 3
    return 'DOWNLOADING';
  case appCache.UPDATEREADY:  // UPDATEREADY == 4
    return 'UPDATEREADY';
  case appCache.OBSOLETE: // OBSOLETE == 5
    return 'OBSOLETE';

With Javascript programming, the application cache can be updated by first issuing an update, then checking the status for completion, and then swapping the cache. Example Javascript is shown below:

var appCache = window.applicationCache;

appCache.update(); // Attempt to update the user's cache.


if (appCache.status == window.applicationCache.UPDATEREADY) {

The application cache is especially useful for HTML5/Javascript-based mobile applications, with which bandwidth and connectivity is potentially an issue.

Hopefully this quick introduction has provided enough information for you to apply it. For more details on the application cache and the details of the HTML5 spec, check out the “Living Specification.”

— David Pitt,

About the Author
David Pitt

David Pitt


David Pitt is a Sr. Solutions Architect and Managing Partner of Keyhole Software with nearly 25 years IT experience. Since 1999, he has been leading and mentoring development teams with software development utilizing Java and .NET technologies. Recent projects involve speaking, writing, and training developers in enterprise JavaScript​/single-page application​ development best practices​, as well as the development of GrokOla, the Q&A-based wiki software​ for development teams.​

Share this Post

Leave a Reply