Storage API

Secure context
This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

Draft
This page is not complete.

The Storage Standard defines a common, shared storage system to be used by all APIs and technologies that store content-accessible data for individual Web sites. The Storage API gives sites' code the ability to find out how much space they can use, how much they are already using, and even control whether or not they need to be alerted before the user agent disposes of site data in order to make room for other things.

Note: This feature is available in Web Workers.

Site storage—the data stored for a Web site which is managed by the Storage Standard—includes:

Site storage units

The site storage system described by the Storage Standard and interacted with using the Storage API consists of a single site storage unit for each origin. In essence, every Web site or Web application has its own storage unit into which its data gets placed. The diagram below shows a site storage pool with three storage units within, showing how storage units can have different data types stored within and may have different quotas (maximum storage limits).

A diagram showing how the site storage pool consists of multiple storage units that contain data from various APIs as well as possible unused space left before the quota is reached.

  • Origin 1 has some Web Storage data as well as some IndexedDB data, but also has some free space left; its current usage hasn't yet reached its quota.
  • Origin 2 has no data stored in it yet; it's just an empty box waiting for content. This origin, however, has a lower quota than the other two do. It may be a less-visited site, or one known to have lower data storage requirements.
  • Origin 3's storage unit is completely full; it's reached its quota and can't store any more data without some existing material being removed.

User agents are likely to use various techniques to determine the quota for various origins. One of the most likely methods—one which the specification specifically encourages, in fact—would be to consider the popularity and/or usage levels of individual sites to determine what their quotas should be.  It's also conceivable that the browser might offer a user interface to customize these quotas.

Box modes

The actual data storage within each site storage unit is called its box. Each site storage unit has exactly one box into which all of its data is placed, and has a box mode that describes the data retention policy for that box. There are two modes:

"best-effort"
The user agent will try to retain the data contained in the box for as long as it can, but will not warn users if storage space runs low and it becomes necessary to clear the box in order to relieve the storage pressure.
"persistent"
The user agent will retain the data as long as possible, clearing all "best-effort" boxes before considering clearing a box marked "persistent". If it becomes necessary to consider clearing persistent boxes, the user agent will notify the user and provide a way to clear one or more persistent boxes as needed.

To change an origin's box mode requires permission to use the "persistent-storage" feature.

Data persistence and clearing

If the site or app has the "persistent-storage" feature permission, it can use the StorageManager.persist() method to request that its box be made persistent. It's also possible for the user agent to decide to make the site's storage unit persistent due to usage characteristics or other metrics. The "persistent-storage" feature's permission-related flags, algorithms, and types are all set to the standard defaults for a permission, except that the permission state must be the same across the entire origin, and that if the permission state isn't "granted" (meaning that for whatever reason, access to the persistent storage feature was denied), the origin's site storage unit's box mode is always "best-effort".

See Using the Permissions API for further details about obtaining and managing permissions.

When clearing site storage units, an origin's box is treated as a single entity; if the user agent needs to clear it and the user approves, the entire data store is cleared rather than providing some means of clearing only data from individual APIs.

example tbd

If a box is marked as "persistent", the contents won't be cleared by the user agent without either the data's origin itself or the user specifically doing so. This includes scenarios such as the user selecting a "Clear Caches" or "Clear Recent History" option. The user will be asked specifically for permission to remove persistent site storage units.

Quotas and usage estimates

The user agent determines, using whatever mechanism it chooses, the maximum amount of storage a given site can use. This maximum is the origin's quota. The amount of this space which is in use by the site is called its usage. Both of these values are estimates; there are several reasons why they're not precise:

  • User agents are encouraged to obscure the exact size of the data used by a given origin, to prevent these values from being used for fingerprinting purposes.
  • De-duplication, compression, and other methods to reduce the physical size of the stored data may be used.
  • Quotas are conservative estimates of the space available for the origin's use, and should be less than the available space on the device to help prevent overruns.

User agents may use any method they choose to determine the size of origins' quotas, and are encouraged by the specification to provide popular or frequently-used sites with extra space.

To determine the estimated quota and usage values for a given origin, use the navigator.storage.estimate() method, which returns a promise that, when resolved, receives a StorageEstimate that contains these figures. For example:

navigator.storage.estimate().then(estimate => {
  // estimate.quota is the estimated quota
  // estimate.usage is the estimated number of bytes used
});

Specifications

Specification Status Comment
Storage Living Standard Initial definition.

Browser compatibility

Feature Chrome Firefox (Gecko) Internet Explorer Opera Safari (WebKit)
Basic support 55.0 51 (51)[1] ? 42 ?
Persistence support (Yes) 55 (55)[2] ? ? ?
Estimates support (Yes) 51 (51) ? ? ?
Feature Android Android Webview Firefox Mobile (Gecko) Firefox OS IE Mobile Opera Mobile Safari Mobile Chrome for Android
Basic support No support 55.0 51.0 (51)[1] ? ? 42 ? 55.0
Persistence support No support (Yes) No support No support ? ? ? (Yes)
Estimates support No support (Yes) 51.0 (51) No support ? ? ? (Yes)

[1] Firefox 51 introduced NavigatorStorage, navigator.storage, and the StorageManager.estimate() method, as well as StorageEstimate. These are enabled by default in nightly builds but disabled by default in all other builds. You can enable these features by setting the preference dom.storageManager.enabled to true. Current supported site storage includes IndexedDB and Cache API data. Web storage API data, history state information will be supported in the future release.
[2] Firefox 55 introduced StorageManager.persist() and StorageManager.persisted() methods. Users can also manage persistent-storage data in Preferences "Privacy and  Security" -> "Site data".  These are enabled by default in nightly builds but disabled by default in all other builds. You can enable these features by setting the preference dom.storageManager.enabled and browser.storageManager.enabled to true.

See also

Document Tags and Contributors

 Contributors to this page: chrisdavidmills, shawn_huang, Sheppy
 Last updated by: chrisdavidmills,