IdxBeaver vs Chrome DevTools Application panel

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).

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.

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.

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.

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.

• 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.