Redux DevTools: a time-travel debugger for Redux and any state container that speaks its protocol

What Redux DevTools actually solves, and who it is for

A Redux store is a black box during development. Actions arrive, reducers run, and the only visible output is whatever the UI happens to render. Redux DevTools exists to open that box: the README describes it as developer tools to "power-up Redux development workflow or any other architecture which handles the state change", and it points to an integrations document for non-Redux architectures. The audience is therefore broader than the name suggests. Front-end engineers debugging a Redux store are the primary users, but anyone whose state container can emit the same messages can attach the same panel. The project ships in three shapes: a browser extension for Chrome, Edge and Firefox; a standalone app under packages/redux-devtools-app; and a React component under packages/redux-devtools that you embed in the client. That spread matters, because the extension is the default answer and the other two exist for situations the extension cannot reach.

How the DevTools panel receives your state and actions

The extension does not read your JavaScript objects directly. Your store has to talk to it. The README separates two layers of documentation: Extension Options (Arguments) and Extension Methods (Advanced API). Arguments are the configuration you pass when creating the store, which is how the store announces itself to the extension and how the extension is told what to display. Methods are the programmatic surface, which is what an integration uses to send actions and state updates over time. The React component path is the same idea with a different transport: instead of a browser extension messaging channel, you render the DevTools UI inside your own application and feed it the store. That is why the README lists manual integration as a separate walkthrough rather than folding it into extension setup. The standalone app and the remote monitoring document cover the case where the inspected application runs somewhere the browser extension cannot reach, such as a device or a remote environment. In all three shapes the data flow is one-directional from your store into a monitoring UI, with replay commands travelling back.

Installing the extension and getting a first store visible

The README points at the extension directory for installation and configuration, and at the extension docs for arguments and methods. The browser stores are linked directly for Chrome, Edge and Firefox. Once the extension is installed, an unmodified store will not appear in it. You have to connect the store, and the package that provides the connection is @redux-devtools/extension, whose 4.0.0 release is listed in the project's recent releases. The README's manual integration walkthrough is the reference for the component path; the extension path is documented under extension/docs.

The README's development section gives the repository's own build commands, which are also the shape a source checkout takes:

pnpm install
pnpm run build:all
pnpm --filter "remotedev-redux-devtools-extension" build

The first command installs the monorepo's dependencies, the second builds every package, and the third builds only the packages the extension needs. After that, dispatching an action in a connected store should make it appear in the extension's action list, and selecting an action should show the state at that point. If nothing appears, the README links a Troubleshooting document, which is the right place to look before assuming the extension failed to install.

The React component route, and when the extension is not enough

Embedding DevTools as a React component is documented in docs/Walkthrough.md under manual integration, and the component lives in packages/redux-devtools. This is the route to take when you cannot install a browser extension: a packaged desktop client, a test harness, or a demo where you want the DevTools visible to someone who will not install anything. The trade-off is that you now ship the DevTools UI inside your application bundle, and you own rendering it. The README does not present the component as a drop-in replacement for the extension, and the walkthrough is a separate document for a reason. Pick the extension for day-to-day development in a browser, and the component when the inspected code runs somewhere a browser extension cannot attach.

Where Redux DevTools is the wrong tool

The first limitation is structural: the project instruments state changes, so a store that never emits them is invisible. If your application keeps state in component-local variables, in a plain module-level object, or in a framework whose state layer has no DevTools integration, installing the extension changes nothing. The README's integrations page exists precisely because non-Redux architectures need their own adapter, and writing that adapter is work the extension will not do for you. The second limitation is that this repository is a monorepo of packages, not a single installable artifact. The root package.json is marked private and its scripts are build and release plumbing (build:all, lint, test, release) run through pnpm, with [email protected] pinned as the package manager. That means contributing or building from source requires pnpm and a recursive build of each package's dependencies before the package itself, as the README states. If you only want the extension, none of that matters, but if you plan to modify the DevTools UI, it is the entry cost. Third, the README does not document a rollback or downgrade path for the extension, so a version that misbehaves has to be handled through your browser's extension management.

How it compares with framework-native devtools

The closest alternative for many teams is the devtools that ship with the state library itself, such as the browser devtools built into a framework's own ecosystem. The difference is in the integration model. Redux DevTools is transport-agnostic: it defines a protocol and lets any store speak it, which is why the README can claim support for architectures beyond Redux. Framework-native devtools assume their own framework's internals and can therefore show more without configuration, but they only work inside that framework. There is also the standalone app in this repository, which competes with nothing so much as the extension itself: same UI, different host, chosen when the inspected process is remote. If your state lives in a Redux store, the extension is the lower-friction option; if it lives in a different container, check the integrations document before assuming Redux DevTools is out of reach.

Maintenance, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-20. The most recent release listed is @redux-devtools/[email protected] on 2026-03-17, with the extension itself at 3.2.10 from 2025-04-03. Those are separate version lines, which is worth noting before you pin anything: the npm package and the browser extension do not move together. The project uses changesets (the .changeset directory and @changesets/cli in devDependencies) and the release script is pnpm build:all followed by pnpm publish -r, so version bumps are recorded as changeset entries. The licence is MIT, which permits commercial use and modification provided the licence and copyright notice are retained; this is a description of the licence text, not legal advice, and your organisation's own review should decide how it applies. The practical upgrade cost is low for consumers of the extension, since browser extension updates are automatic, and higher for anyone building from source, where pnpm install followed by a recursive build is required.

Editorial conclusion

Adopt Redux DevTools if your application keeps state in a Redux store or any container that can emit the DevTools protocol, and you need to see action payloads and state diffs while debugging. Do not adopt it as a state management library, and do not expect it to instrument a store you never wired up. Before you rely on it, verify which of the three delivery shapes fits your target (extension, standalone app, or React component), and check the Troubleshooting page for your specific symptom rather than assuming the extension is broken.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. reduxjs/redux-devtools on GitHub
5. Releases