At a glance

Capability	IdxBeaver	Application panel
Storage surfaces	IndexedDB, LocalStorage, SessionStorage, Cookies, Cache Storage	Same set, plus Service Workers and Web SQL (deprecated)
Inline grid editing	Type a value, hit enter, undo/redo per cell
Query language	MongoDB-style filters, projection, sort, limit; index-aware planner
Schema inference	Sampled per store; powers autocomplete + Structure view + TS/Dexie export
Multi-tab editor	Several queries open per origin, switchable like browser tabs
Saved queries + history	Per-origin; auto-trim to 100 most recent
Bulk filter → edit/delete	First-class via the grid
Import	JSON, NDJSON, CSV, SQL INSERT, ZIP
Export beyond a single row	JSON, NDJSON, CSV, SQL INSERT, ZIP snapshots, TS/Dexie schema	Right-click → copy single record
Multi-frame discovery	Scans every scriptable frame on the page	Top frame only in most flows
Non-JSON type round-trip	BigInt, Date, RegExp, Map, Set, ArrayBuffer, Blob, circular refs	Limited — many types stringify
Column pin / resize / sticky headers
Virtualized grid for large stores	Yes — hundreds of thousands of rows scroll without jank
Service Worker debugging		Yes — first-party DevTools integration
Open source	Yes — MIT licensed, source on GitHub	Closed (part of Chrome)
Telemetry		Same as Chrome itself

Where the Application panel is enough

Don’t over-engineer. If your workflow is “is the value still in IndexedDB after the latest deploy?” or “clear this LocalStorage key,” the built-in panel does the job. Specifically:

One-off lookup of a key/value pair.
Eyeballing a small object store (under ~50 rows).
Wiping a database during local development.
Watching a Service Worker’s lifecycle (IdxBeaver doesn’t touch SW debugging — that’s squarely DevTools’ lane).

Where IdxBeaver pays off

IdxBeaver's IndexedDB data grid open in Chrome DevTools, showing an object store with pinned columns and an inspected row — The same object store the Application panel lists, rendered as a sortable, editable grid with a row inspector.

1. You actually need to query the data

Once a store has more than a few hundred rows, scrolling and squinting stops working. IdxBeaver lets you write filters directly:

{
  "store": "orders",
  "filter": {
    "status": "delivered",
    "total":  { "$gte": 20000 },
    "createdAt": { "$gte": "2026-01-01" }
  },
  "sort":  { "createdAt": -1 },
  "limit": 50
}

The planner inspects the filter for single-field equality/range expressions and uses an IDBIndex when one matches. Compound operators fall back to an in-memory match on the result of the index scan. Either way, the chosen plan is reported alongside results so you can spot a missing index.

The IdxBeaver query editor running a MongoDB-style filter against an IndexedDB object store, with the chosen query plan shown beside the results — The query editor reports which plan it used, so a missing index is visible rather than inferred.

2. The schema isn’t obvious

On a real app, an object store is rarely a flat shape. IdxBeaver samples the rows and shows you what fields exist, their types, and their coverage (“90% of rows have ashippingCity string”). That powers autocomplete in the query editor and a Structure view you can export to a TypeScript interface or a Dexie schema. Useful when onboarding new contributors or auditing what your client app actually persists.

3. You need to round-trip data

The Application panel can copy a single record. IdxBeaver exports a whole filtered slice — JSON, NDJSON, CSV for spreadsheet handoff, SQL INSERT statements for replays into a seed script, or a ZIP snapshot of the entire database. Imports preserve non-JSON types (BigInt, Date, RegExp, Map, Set, ArrayBuffer, Blob) by serializing through a versioned wire format.

4. You’re editing at scale

Inline edits in the grid are first-class: type a value, hit enter, and the change is committed with a per-cell undo entry. Undo/redo stacks are capped per store, so a fat-finger doesn’t become irreversible. The Application panel doesn’t expose a writable grid for nested fields at all.

5. Multiple frames, same origin

IndexedDB is partitioned per frame origin. Apps that embed cross-origin iframes (auth, payments, embedded dashboards) end up with multiple databases the parent frame can’t see. IdxBeaver scans every scriptable frame in parallel and merges the results; the built-in panel typically only surfaces the top frame.

Performance and footprint

IdxBeaver is a regular MV3 extension: a service worker that routes RPC requests, a panel React app, and an injected execution context that runs the cursor loop in the inspected page’s MAIN world. The grid itself is virtualized, so a store with hundreds of thousands of rows scrolls without jank. Reads happen on demand — opening a database doesn’t pre-fetch every store.

The Application panel is part of DevTools and has tighter integration with the renderer, but no virtualization for large stores. For tables over ~10k rows, expect the panel to slow down noticeably. Both tools share the same IndexedDB API constraints — you can’t do anything Chrome itself can’t do.

Privacy comparison

Both tools are local-only. IdxBeaver makes no network requests (no telemetry, no analytics, no remote config), and its source is MIT-licensed on GitHub — you can audit it. Chrome’s Application panel is similarly local but is part of a closed-source binary; trust it to the same degree you trust Chrome itself.

When to use which

Use the Application panel for one-off lookups, service-worker debugging, and clearing storage during local development.
Use IdxBeaverwhen you need to filter, sort, edit in bulk, export, import, share queries with teammates, or understand the shape of a store you didn’t design.

IdxBeaver vs Chrome DevTools Application panel