Nuxt DevTools v4 · Nuxt Blog

Releases·Oct 28, 2026·7 min read
Nuxt DevTools v4 is built on Devframe and Vite DevTools. It brings the full Vue DevTools and the wider devtools ecosystem to Nuxt.
We are happy to announce Nuxt DevTools v4.
Nuxt DevTools v4 is built on top of Devframe and Vite DevTools. Because of this, Nuxt can now reuse the whole devtools ecosystem. We also no longer vendor Vue DevTools. You now get the full Vue DevTools, with all of its features.
You do not need to change anything in your app. Open the DevTools in the same way as before. The shortcut is Shift + Option + D (macOS) or Shift + Alt + D (Windows).
Since v1.0, the Nuxt DevTools grew in a way that only worked for Nuxt. Each module that wanted a panel had to use our own API. Each feature from Vue DevTools had to be copied into our code. This was a lot of work for us, and it was hard to keep in sync.
We wanted to fix this at the root. The problem is not only about Nuxt. Every tool in the JavaScript world needs the same things: a panel, a way to talk to the server, and a way to show data. This has always been our vision to provide a generalized, unified devtools experience for the ecosystem to share and build upon.
So we built Devframe, the framework-agnostic and agentic toolkit for devtools, and now Vite DevTools, Vue DevTools, and Nuxt DevTools all run on top of it.
Devframe is a toolkit for building devtools, agnostic of any specific framework or tool. You describe a devtool once, with its panels, typed RPC, and shared state, and the same definition runs in any host: Nuxt, Vite, Next.js, a standalone CLI, a static report, or an MCP server for coding agents. Think of it as unplugin for devtools.
Under the hood, a devframe is exposed as a plain Request → Response handler, and a hub can compose many devframes behind one handler. You can learn more in the Devframe repository and its announcement post.
With v4, Nuxt joins the same ecosystem as Vite and other tools. This works in two directions:
The picture above shows how this composes for Nuxt. Most of what you see in the panel is not written for Nuxt at all. Tools like accessibility checks, terminals, and the data inspector are general, so every host gets them. Vite's own tools, like Vitest, Rolldown, and Oxlint, come with the build tool. Only the framework-specific layer, such as Vue's components and reactivity, Pinia, or Nuxt modules and auto imports, is specific to the framework. Community tools like UnoCSS or the ESLint Config Inspector plug in the same way.
Other hosts pick their own combination. A DevTools for Next.js or Svelte could reuse the same general and build tool layers, and only add its own framework-specific part. That means a new host starts with a rich set of tools, and every tool you write reaches more users.
You build a panel once, and many people can use it.
Thanks to Devframe, the latest Vue DevTools and Vite DevTools are now fully built on top of it. The stack has three layers, and each layer inherits and extends the one above:
This is why we no longer need to vendor Vue DevTools. Instead of copying its features into our code, Nuxt DevTools inherits them, so you always get the complete and up-to-date Vue DevTools. Improvements to Vite DevTools reach Nuxt without extra work from us.
Under the hood, every devtool is a devframe that can run alone, join a hub, or mount into any host through the same standard handler. Vite DevTools is one host, and framework-specific hosts like Vue DevTools and Nuxt DevTools inherit and extend it.
Regardless of the underlying architecture having undergone an overhaul and restructuring, the user-facing experience remains consistent, as we always aim to make progressive releases and make the migration smooth.
Nuxt DevTools v4 is a transition release.
We know that many modules use the previous Nuxt DevTools API from @nuxt/devtools-kit. If your module uses that API, it keeps working in v4. We added a shim that maps the old API to the new system. In development, the shim logs a warning so that you know which module to update.
The shim is only there to give you time. We recommend that you move your module to one of the new APIs:
The old @nuxt/devtools-kit helpers map to the new context one by one. Each deprecated helper now logs a diagnostic code, so you can find the exact call to update:
Here is how a panel looks before and after the move to the Vite DevTools context:
If you want your tool to run beyond Nuxt, define it once with defineDevframe() and keep the Nuxt module as a thin wrapper. The RPC functions are typed, validated with any Standard Schema library, and namespaced by your devframe id:
Then you can ship the same definition through whichever entry points suit your users:
If the UI of your tool is a Nuxt app, @devframes/nuxt/single wires it up as the browser side of a devframe and gives you a typed $rpc client in useNuxtApp().
Head to the Devframe documentation to learn more, including a step-by-step tutorial that builds a data inspector from scratch.
The easiest way to try Nuxt DevTools v4 is to use Nuxt 5, as it ships with DevTools v4 by default.
If you are on Nuxt v4.5+ and want to try out Nuxt DevTools v4, you can do so by adding it as a module:
This release would not be possible without the people behind Devframe, Vite DevTools, and Vue DevTools. Thank you to all the contributors who helped to build Devframe and to make these tools work together.
Please try the new Nuxt DevTools and let us know what you think. Feel free to open issues on GitHub.
Nuxt 4.6 makes Nuxt server-agnostic with nuxt/server, rebuilds typed $fetch, adds sessions, Vue Vapor support and new dev error pages, and ships alongside Nuxt CLI v4.
Stay updated on new releases and features, guides, and community updates.
Copyright © 2016-2026 Nuxt - MIT License