IndexedDB Test

It would be easy to report whether the indexedDB object exists and stop there. That proves almost nothing: the property is present in browsers that then refuse to open a database. So this test opens a real one, creates an object store, writes a record into it, reads the record back and compares it.

Only when all of that succeeds does the panel call IndexedDB working. The probe database is named bs-indexeddb-probe, and it is deleted again as soon as the round trip is finished, so nothing is left on disk after you close the page.

The quota figure comes from navigator.storage.estimate(), part of the Storage Manager API. It returns two numbers: how much space this origin is allowed, and how much it is currently using. Browsers derive the quota from the free space on the disk rather than granting a fixed allowance, so a machine with a large empty drive reports a much larger figure than a nearly full one, and the same origin can see the number change over time.

Treat both values as estimates. Usage covers cookies, local storage, IndexedDB, CacheStorage and service worker caches together, and browsers round and cache the figure, so it will not move the instant you write a few kilobytes. The meter above puts usage against quota, which in practice almost always reads as a fraction of one per cent.

If the API is missing altogether, which is still the case in some builds, both rows read as not available rather than showing a guess. The cookies and storage test covers the smaller stores that share this same budget.

navigator.storage.persisted() answers a different question from quota: will the browser keep this origin’s data, or is it free to delete it under pressure? Every origin starts as best-effort, which means a browser running low on space may evict the whole store without asking. Persistence moves it into a protected bucket that automatic cleanup leaves alone.

The catch is that a page cannot simply take it. Chromium grants persistence after a prompt in most cases, or silently when the site is installed as an app or has been engaged with repeatedly. Firefox shows its own prompt. Because a request needs a user gesture, no test page can change the answer for you, and this one reports the current state without asking.

That split matters for the tools that use storage heavily. A note-taking app that loses a draft to eviction is a broken app, so it should request persistence; a cache of thumbnails should not, because it can simply be rebuilt. The same reasoning applies to the evercookie test, where eviction is the behaviour you actually want.

IndexedDB is present in every current browser, so a failure here is nearly always a policy decision rather than a missing feature. The rows above name the stage that failed, which narrows it down.

• Open blocked. Strict privacy settings, or a page running inside a third-party frame, can refuse the open outright.
• Blocked by another tab. If a previous version of the probe database is still open elsewhere, the upgrade waits and the request is reported as blocked.
• Transaction threw. This happens in private windows of some builds, where the open succeeds and the write is then refused.

A failure is not harmful, but it does mean a site that stores work offline will lose it. The local storage test tells you whether the smaller store survives in the same environment.

IndexedDB’s size is what makes it interesting to trackers. A few hundred megabytes of quota holds an identifier just as happily as it holds a document, and the store survives closing the browser, so it is a natural second home for a value that was originally set as a cookie.

It is still local data, and local data can be deleted. Clearing site data for an origin removes its databases along with its cookies, which is the practical defence. What no amount of clearing touches is a browser fingerprint, because that stores nothing at all and is recalculated from your device each time you arrive.