react-router-devtools: A Vite Plugin That Puts a Debug Panel Inside Your React Router v7 App
Debug your apps, find hydration errors, trace your network and more in your react-router app with these devtools
At a glance
- What is it?
- react-router-devtools is an MIT-licensed TypeScript package that mounts an in-app panel for inspecting loaders, routes, network requests and hydration errors in React Router v7+. It is a development-only tool, and its usefulness depends on whether you are already on the Vite plugin pipeline.
- Who is it for?
- Adopt react-router-devtools if your React Router v7 app is built through Vite and you spend time reconstructing loader data and route trees by hand in the browser. Skip it if you are not on Vite, or if you need a tool that works in production.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 49 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap react-router-devtools fills in a React Router v7 project
React Router v7 merges routing with server-side data loading. A route module can export a loader, an action, and a component, and the framework decides when each runs. When something goes wrong, the failure is rarely in one place. A loader returns the wrong shape, a parent route revalidates, a request is aborted mid-flight, and the component renders with stale data. The browser devtools show you a fetch waterfall and a DOM tree, but they do not tell you which route module owns a given request or what the loader actually returned.
react-router-devtools targets that gap. According to the README, it provides an interface with tabs for Active Page, Terminal, Settings, Errors, Network and Routes, plus a side tab called Timeline. The stated purpose is monitoring page information, URL parameters, server responses, loader data and routes. The README also names hydration issues and route tree inspection as first-class concerns, which fits the audience: developers working on React Router v7+ apps who need to see framework-level state rather than DOM-level state. It is a development aid, not a production monitoring product, and nothing in the material suggests otherwise.
What the plugin actually installs into your build
The install path is a Vite plugin. The README shows `npm install react-router-devtools -D`, then importing `reactRouterDevTools` from the package and adding it to the plugins array in `vite.config.js` alongside `reactRouter()` and `tsconfigPaths()`. The README's own words after that step are "That's it, you're done!"
Because it is a plugin rather than a browser extension, the panel is injected into the dev server build. That design choice explains most of the tool's behaviour. The plugin can read the route manifest and loader results at the point where the framework produces them, which a browser extension could not do without patching globals. It also means the tool ships with your app's dev bundle and disappears from production builds, assuming the plugin is only present in the development config. The README does not spell out that last assumption, so treat it as something to verify in your own Vite config rather than a documented guarantee.
The README mentions a CloudFlare section, telling users who are "trying to spin it up on CF" to add entries to `optimizeDeps` in `vite.config.js`. The snippet shown is the `optimizeDeps: { include: [...] }` block with a placeholder comment, so the README does not list which dependencies to include. That is a documentation gap worth noting before you deploy to CloudFlare Workers.
Routes, loaders and network requests as inspectable objects
The Routes tab presents routes in a tree or list view, per the README. For a nested React Router v7 app this is the view that answers which layout route wraps which child, and where a loader is attached. Reconstructing that by reading route config files gets harder as the tree deepens, especially when routes are generated or split across files.
The Network tab is described as tracing all network requests in real time, with indicators for whether a request was aborted, cached, or successful. Aborted and cached states are the interesting ones. A request that never completes and a request served from cache can look identical in a component that renders the same fallback for both. The README does not describe how the plugin distinguishes these states internally, so the mechanism behind the labels is not something I can confirm from the material.
The Errors tab is aimed at hydration issues. React Router v7 supports server rendering, and hydration mismatches are among the least pleasant failures to debug, because the stack trace often points at a component that rendered correctly on the server. The README states the tab helps track these down but does not give an example of what a hydration report contains. That is the section I would want expanded most, and it is the one the README leaves thinnest.
Getting it running, and the CloudFlare caveat
Two commands and one config edit cover the documented path. Install as a dev dependency with `npm install react-router-devtools -D`. Then in `vite.config.js`, import `reactRouterDevTools` from `react-router-devtools` and place `reactRouterDevTools()` in the plugins array. The README's example orders it before `reactRouter()` and `tsconfigPaths()`.
If you run on CloudFlare, the README adds a second step: add entries to the `optimizeDeps.include` array in `vite.config.js`. The README shows the shape of the block but not its contents, so you will need the documentation site at react-router-devtools.fly.dev for the actual dependency list. This is the one place where following the README literally will not get you to a working setup on that platform.
The README also points to a separate documentation site, and notes that the project was formerly called remix-development-tools. The old package lives on a branch named `remix-development-tools`, and the older documentation is hosted at remix-development-tools.fly.dev. If you are migrating from the old package, note that the two documentation sites are different URLs, which is easy to miss when following a search result.
Where this tool stops being the right choice
The largest constraint is the framework requirement. The README frames the package as being "for React Router v7+", and the repository topics include react-router-v7. Projects on React Router v6, or on a non-Vite bundler, are outside the documented support surface. There is no statement in the material about supporting other bundlers or other router versions, so I would not assume it.
The second constraint is the dev-only posture. A plugin-based panel lives in the development build. If you need to understand what a loader returns in a staging environment that behaves differently from local, this tool will not be there unless you deliberately enable it, and the README does not describe a supported way to do that. Production debugging is out of scope.
The third is documentation depth. The README is a getting-started document, not a reference. It names six tabs plus a Timeline side tab but describes the contents of only a few. The CloudFlare section is a stub. Anyone evaluating the package should read the external documentation site before deciding, because the README alone does not answer what each panel shows in enough detail to judge fit.
How it differs from the browser's own network panel
The obvious alternative is Chrome DevTools or Firefox Developer Tools, which every engineer already has. The difference is the unit of analysis. Browser devtools group activity by request and by frame. react-router-devtools groups it by route and by loader, which is the unit a React Router developer actually reasons about. When a parent route revalidates and three child loaders refetch, the browser network panel shows four entries with no indication that they belong to one navigation. The Routes and Network tabs, as described, are organized around that relationship.
That advantage is also the limitation. Because the panel is coupled to React Router's internals, it only works where React Router is running in a way the plugin can instrument, which in practice means the Vite dev server. Browser devtools work everywhere, including production, on any framework, with no install step. The honest framing is that these are complements. Keep the browser network panel open for TLS, caching headers and payload sizes; use react-router-devtools for the route and loader layer above it. The README does not claim to replace browser devtools, and it should not be read that way.
Maintenance cost, versioning and the MIT licence
The package is released under the MIT License, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement and it imposes no copyleft obligation on your application. This is a description of the licence text, not legal advice; if your organisation has specific policy around bundled dev dependencies, route it through whoever handles that.
Release cadence is visible in the supplied material: 6.2.3 and 6.2.2 both dated 2026-07-28, and 6.2.1 dated 2026-06-01. That is a minor-version line moving within a single day at the top, which suggests active patching. The repository is not archived and the last push matches the most recent release timestamp. None of this tells you whether the API is stable, and the README does not include a compatibility table tying package versions to React Router versions. Since the package instruments framework internals, a React Router minor release is the event most likely to break it. Pin the version in your lockfile and read the release notes before bumping either side.
Installing it as a dev dependency, as the README instructs, keeps it out of your production dependency tree, which limits both bundle impact and supply-chain surface to development machines and CI.
Editorial conclusion
Adopt react-router-devtools if your React Router v7 app is built through Vite and you spend time reconstructing loader data and route trees by hand in the browser. Skip it if you are not on Vite, or if you need a tool that works in production. Before installing, open the linked documentation site, confirm the current install instructions still match the README, and check the CloudFlare optimizeDeps note if you deploy to CloudFlare Workers.
Community notes