IndexedDB: Browser Support, Storage Limits, Known Issues

What is IndexedDB?

IndexedDB is a low-level JavaScript API maintained by W3C and WHATWG for storing significant amounts of structured data, including files and blobs, inside the browser. The window.indexedDB property exposes the entry point, and every read or write happens inside a transaction against an object store keyed by an index.

Which browsers does IndexedDB support?

IndexedDB ships by default in every modern browser engine, including Blink, Gecko, and WebKit, covering Chrome, Edge, Firefox, Safari, Opera, Samsung Internet, and the Android Browser.

What are the key features of IndexedDB?

IndexedDB is built around five design choices that separate it from cookies, localStorage, and sessionStorage. Each one shapes how you should structure code that reads or writes data.

• Asynchronous, non-blocking API: Every operation returns an IDBRequest and runs off the main thread, so large reads and writes do not freeze the UI.
• Transactional: Every read and write must run inside a transaction. The browser commits the transaction atomically or rolls it back on error, which keeps stored data consistent.
• Structured-clone serialization: IndexedDB stores any value the structured clone algorithm can serialize, including JavaScript objects, arrays, ArrayBuffers, Blobs, and Files. JSON conversion is not required.
• Indexed object stores: Data lives in object stores keyed by a primary key, with secondary indexes that let you query by any field. This is what makes IndexedDB feel like a NoSQL database instead of a key-value bucket.
• Same-origin isolation: Each database is scoped to a single origin (scheme, host, and port), so a page on example.com cannot read a database created by another origin.

What are the storage limits for IndexedDB?

IndexedDB uses a percentage of the user's free disk space, not a fixed cap. The exact percentage depends on the browser, the storage pressure, and whether the origin is marked as persistent.

• Chrome and Edge: Each origin can use up to 60 percent of total disk space, with the browser ceiling at 80 percent across all origins. Incognito mode caps the quota near 5 percent. Chrome evicts data from non-persistent origins under storage pressure, starting with the least recently used.
• Firefox: Each origin can use up to 50 percent of free disk space, capped near 2 GB per group of related origins (eTLD+1). Firefox evicts on a least-recently-used basis when the global quota fills.
• Safari: Each origin starts with about 1 GB and prompts the user for more in 200 MB increments. Safari aggressively evicts data after seven days of no user interaction under Intelligent Tracking Prevention. Installed PWAs added to the home screen are exempt from the seven-day cap.
• Internet Explorer: Capped at 250 MB per origin and 1 GB total across all sites in IE 10 and IE 11.

Call navigator.storage.persist() to mark the storage as persistent so the browser does not evict your data under pressure. Call navigator.storage.estimate() to read the current usage and quota at runtime.

What are the known issues with IndexedDB?

IndexedDB has shipped in every major browser for over a decade, but several long-standing bugs and quirks still surprise teams. In my experience, the Safari Private Browsing rejection and the Firefox Private Browsing block account for most of the cross-browser bug reports a QA team will see on storage-heavy apps.

• Safari iOS page-load eviction: Safari 14 to 14.5 shipped a regression where IndexedDB databases were occasionally wiped on page load. Apple patched it in Safari 14.6, but apps that target older iOS users still need a recovery path for cached data.
• Firefox Private Browsing throws: indexedDB.open() rejects with InvalidStateError inside a Private window. Detect Private Browsing at runtime and fall back to in-memory storage so the page does not error out.
• Safari Intelligent Tracking Prevention: Safari evicts IndexedDB data after seven days without user interaction with the site. Critical state must be stored persistently with navigator.storage.persist() or replicated to a server.
• Internet Explorer is partial only: IE 10 and IE 11 lack compound indexes, IDBObjectStore.getAll(), and several other parts of the spec. Treat IE as unsupported in new builds; Microsoft has retired it.
• Inconsistent binary key handling: Some browsers accept binary key paths and others reject them. Keep keys to strings, numbers, or arrays of strings and numbers for portable code across Chrome, Firefox, and Safari.
• Verbose, callback-heavy API: The raw IndexedDB API is event-driven and noisy compared with modern Promise-based APIs. Most teams ship a wrapper such as Dexie or idb to keep call sites readable.

Citations

All IndexedDB version numbers and platform notes in this guide come from these primary sources:

• W3C - Indexed Database API 3.0: w3.org/TR/IndexedDB
• W3C - Indexed Database API 2.0 Recommendation: w3.org/TR/IndexedDB-2
• MDN Web Docs - IndexedDB API: developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
• MDN Web Docs - Window.indexedDB: developer.mozilla.org/en-US/docs/Web/API/Window/indexedDB
• MDN Web Docs - StorageManager: developer.mozilla.org/en-US/docs/Web/API/StorageManager
• web.dev - Working with IndexedDB: web.dev/articles/indexeddb
• web.dev - Storage for the web: web.dev/articles/storage-for-the-web
• Chrome for Developers - IndexedDB DevTools: developer.chrome.com/docs/devtools/storage/indexeddb
• Wikipedia - IndexedDB: en.wikipedia.org/wiki/IndexedDB