Nuxt DevTools: visual debugging for a Nuxt app, and how to opt in to v4

What Nuxt DevTools is for, and who should care

Nuxt DevTools is not the browser's own developer tools. It is a Nuxt module that adds a visual panel inside your running app, described in the README as "a set of visual tools that help you to know your app better." The target reader is someone building a Nuxt application who wants to see what the framework is doing without reading generated files or adding console statements.

The panel is split into tabs, and the README's telemetry section names navigations between tabs as one of the collected events, which tells you the tab structure is the primary navigation model. Because it is a Nuxt module rather than a browser extension, it only exists inside a Nuxt dev server. If you are debugging a static HTML page, a non-Nuxt framework, or a production build served from a CDN, this is the wrong tool and the browser's own panels are what you want.

The project is MIT licensed and the repository is a pnpm monorepo with a turbo build, so the published package is assembled from packages under packages/ rather than shipped from a single flat source tree.

Opening the panel and the devtools key in nuxt.config.ts

In Nuxt 3.8.0 and later, Nuxt DevTools is enabled by default. There is nothing to install for the common case. Start your dev server and press Shift + Alt + D, or Shift + Option + D on macOS, inside the app to open the panel.

If you need to be explicit, the README shows the devtools key in nuxt.config. Setting enabled to false is the documented way to turn the panel off, which matters for anyone who finds the overlay distracting or wants a clean screenshot.

// nuxt.config.ts
export default defineNuxtConfig({
  devtools: {
    // Enable devtools (default: true)
    enabled: true,
  },
})

The same options object carries a codeServer entry, which the README notes is enabled by default. The README points at the type definition file for the full option list rather than enumerating it, so the TSDoc in your editor is the authoritative reference here. That is a real gap: the README tells you the key exists and then hands you off.

Installing and opting in to the v4 alpha

The main branch in this repository is the v4 development line, and the README states plainly that the latest stable branch is v3. The most recent published releases are v4.0.0-beta.1, v4.0.0-alpha.20 and v4.0.0-alpha.19, so what is on main is pre-release code.

Because Nuxt ships with a built-in version of DevTools, you cannot simply install a newer one and expect it to win. The README's approach is a package manager override that redirects the bundled package name to the nightly distribution. For npm that goes in package.json:

{
  "overrides": {
    "@nuxt/devtools": "npm:@nuxt/devtools-nightly@latest"
  }
}

Yarn uses a resolutions block and pnpm nests the same mapping under a pnpm.overrides key. After editing, the README instructs you to remove the lockfile (package-lock.json, yarn.lock or pnpm-lock.yaml) and reinstall dependencies. That step is not optional in practice: an override that conflicts with a stale lockfile is exactly the kind of thing that silently keeps the old version.

The nightly channel is a separate decision from v4. According to the README it releases automatically for every commit to main, so the version you resolve today is not the version you resolve tomorrow. Nuxt DevTools v2 requires Nuxt v3.15.0 or higher, so check that floor before chasing any of this.

Telemetry, DO_NOT_TRACK and what actually leaves your machine

Nuxt DevTools collects anonymous usage telemetry, and the README is unusually specific about the mechanism. Data is piped through Nuxt Telemetry, which means the module inherits your existing local and global Nuxt Telemetry settings rather than maintaining a separate consent state. There is also a second switch inside the Nuxt DevTools settings.

The environment variable path is the blunt one: setting DO_NOT_TRACK=1 disables Nuxt DevTools telemetry regardless of any other setting. If you work in an environment where outbound calls from a dev server are audited, that single variable is the lever.

The collected events beyond the default Nuxt Telemetry set are versions of Nuxt DevTools, tab navigation, browser and OS names and versions, and clicks on some action buttons. The README says the data is anonymous, not traceable to the source using hash plus seed, and meaningful only in aggregate. Nothing in the repository contradicts that, but the list is worth reading before you assume telemetry means only a version ping: tab navigation reveals which features get used, and browser and OS data is fingerprinting-adjacent even when hashed.

Where Nuxt DevTools stops being the right answer

The clearest limitation is scope. Nuxt DevTools is a Nuxt module. It has no meaning in a Vue app that is not using Nuxt, in a SvelteKit or Remix project, or in a plain static site. The browser's own DevTools panels, which is what most search traffic for the word devtools is actually about, cover those cases and cover them regardless of framework.

The second limitation is the release channel. The repository's main branch is v4 development and the newest tags are alpha and beta releases. Anyone who follows the README's override instructions is opting into code that changes with every commit to main. That is a reasonable trade for someone who wants to test a specific fix, and a poor one for a team that needs a reproducible dev environment, because the resolved version is not pinned by anything in the override snippet.

The third is documentation depth. The README links out to the announcement blog post for the feature list instead of describing features inline, and it defers the full option set to a type definition file. You can operate the panel from the README alone, but you cannot learn what the individual tabs do from it.

How it differs from reaching for the browser panels first

The browser's built-in developer tools are the real alternative, and the difference is architectural rather than a matter of polish. Browser DevTools attach to the page from outside: they see the DOM, the network waterfall, the console and the JavaScript runtime, and they know nothing about Nuxt. Nuxt DevTools runs as part of the Nuxt dev server and renders its UI inside the app, which is why it can present framework-level information such as the routes and modules Nuxt generated, and why it disappears the moment you are not running a Nuxt dev server.

That split decides which one you open. Layout problems, requests, and runtime errors are browser panel work in any framework. Questions about what Nuxt itself assembled are where the module earns its place. The two are not exclusive, and the keyboard shortcut is deliberately inside the app rather than in a browser menu, so the intended workflow is to keep both available.

There is also a practical difference in setup cost. The browser panels are always there. Nuxt DevTools needs Nuxt 3.8.0 or later to be present by default, and Nuxt 3.15.0 or later for the v2 line, so on an older project you are upgrading Nuxt before you are debugging with this.

Editorial conclusion

Adopt Nuxt DevTools if you build Nuxt apps, because it arrives with Nuxt itself and needs no separate install to try. Skip it if you are not on Nuxt, and think twice before pinning the alpha v4 nightly in a shared repository. Verify first that your Nuxt version is at least 3.15.0, then check whether the devtools key in nuxt.config.ts or a package manager override is what is actually controlling the version you run.

Frequently asked questions

Official sources

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