Storage limits on Chrome browser

Update May 2020: Chrome now lets an origin use 60% of the storage device's space (Real nitty gritty: "storage device" is the partition containing the chrome profile directory). Updated article here https://web.dev/storage-for-the-web/#how-much

The rule of thumb is 6% (edit 2015-Jul: was 10%) of the available space on the user's hard drive, less if your origin is using websql, appcache or the filesystem api. The MDN doc mentioning 5mb was outdated and has been updated. The gory details about the current policy are here: https://developer.chrome.com/apps/offline_storage

Note some annoying subtleties:

1. There is no PERSISTENT storage for indexeddb, only the stuff in the link above about TEMPORARY applies.
2. Once your origin exhausts its share of the pool,indexeddb transactions will unhelpfully abort with no real indication why. As of now the only way to determine that lack of quota is the cause is to use queryUsageAndQuota to check how much space is left. Hopefully a future version of chrome will soon properly fill out IDBTransaction.error in these cases. Edit: chrome 26 now properly fills out IDBTransaction.error with QuotaExceededError.
3. There is currently no API to request more storage space for indexeddb.

Check quota with following code in chrome>dev tools(F12)>console

// Request storage usage and capacity left
window.webkitStorageInfo.queryUsageAndQuota(webkitStorageInfo.TEMPORARY, 
//the type can be either TEMPORARY or PERSISTENT
function(used, remaining) {
  console.log("Used quota: " + used + ", remaining quota: " + remaining);
}, function(e) {
  console.log('Error', e); 
} );

Warning - this information is outdated - see the other answer below.

Chrome has a 5mb soft limit before it hits a QUOTA_ERR. Here's a MDN reference to that fact.

The spec mentions a QuotaExceededError but doesn't seem to say anything about when it should be thrown.

QuotaExceededError The operation failed because there was not enough remaining storage space, or the storage quota was reached and the user declined to give more space to the database.

I've not heard of a hard limit and not reached one in my own development. Performance should go pretty far south before you reach it.