b2KIT

IndexedDB Explorer

Browse, query, and manage IndexedDB databases in your browser with table views and CRUD operations.

Tested tool guide Tested browser tools Checked August 16, 2026

What IndexedDB Explorer does and how it behaves

IndexedDB Explorer turns an origin's IndexedDB databases into navigable database, object-store, index, and record views. Select a store to inspect its keys and values in a table, narrow what is shown with the query controls, and perform create, read, update, or delete operations on client-side records. This answers questions about what structured browser data currently exists and lets you correct test data without writing an IndexedDB script. Inspection and edits happen inside the browser; database content is not uploaded. The important boundary is origin isolation: the page cannot open an unrelated site's storage, even when both sites are open in the same browser.

How the result is produced

1

Database navigation

Start with a database visible to the current origin, then choose one of its object stores. The selected store supplies the records rendered in the table. IndexedDB stores values under keys, and an object store can also expose indexes over properties of those values. An index is an alternate lookup and ordering path; it is not a second copy for independent editing.

2

Record changes

Create and update operations must respect the selected store's key rules. With an inline key, the key is derived from the stored value using the object's store key path, which can be a dotted path or an array of paths forming a compound key. With an out-of-line key, the key is supplied separately from the value; an auto-increment store can generate keys. A delete targets the selected record's key. Each write changes browser storage for that origin, so confirm both database and store before applying it.

Good uses

  • Inspect an application's IndexedDB cache after a page flow to confirm which record key, nested value, or indexable field was actually stored.
  • Edit or remove one malformed development record that prevents an application from loading, then reload the application to test its recovery behavior.
  • Seed a small set of deterministic records in a test object store and verify that subsequent reads, updates, and deletions affect the intended keys.

Limits and checks

  • Visibility is origin-scoped. Scheme, host, and port determine the origin, while browser profiles and private-browsing contexts have separate storage. An empty database list does not prove that IndexedDB is unused elsewhere.
  • The table presents object-store values, not a relational schema. Nested objects, arrays, dates, blobs, and typed data may need closer inspection; displayed columns do not imply SQL types, joins, or relational constraints.
  • CRUD actions mutate live data in the selected database. Application code can ignore, overwrite, migrate, or recreate those records later. Deleting a record is also different from deleting an object store or an entire database.

Common questions

Why is the database I expect missing?

Verify the exact scheme, host, and port where the database was created, then use the same browser profile and browsing mode. Some applications create their database only after a particular feature runs. If the database belongs to another origin, the explorer page cannot cross that security boundary to display it.

Does a successful edit immediately change the application's screen?

Not necessarily. The stored record changes, but a running application may retain an older value in memory or read storage only during startup. Reloading may cause another read, but application code can also normalize or replace your edit. Treat the explorer's table as the current storage state, not necessarily the application's current UI state.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools