Nuxt DevTools: The Embedded Developer Panel in Detail

1. What sets Nuxt DevTools apart from the Vue browser extension

Nuxt DevTools is a standalone tool that differs clearly from the classic Vue browser extension.

While Vue DevTools is installed as a browser extension and focuses on the component tree, props and Pinia stores of a running Vue application, Nuxt DevTools is embedded directly in the Vite dev server of a Nuxt 3 project and opened through a floating icon at the edge of the screen. No extension store, no separate browser install, no permission that needs approval per domain.

The second fundamental difference is scope.

Nuxt DevTools does not only show reactive component state, it shows the whole project: loaded modules, auto-import origin, server routes, static assets, build times, and even the content of the Nuxt configuration itself. Nuxt DevTools understands the project structure on a level a pure runtime extension cannot reach, because much of this information only exists at build time or comes from the file system.

Important for framing this correctly: Nuxt DevTools does not replace Vue DevTools, it complements it. A dedicated tab in the Nuxt DevTools panel even embeds the classic Vue DevTools directly, so component inspection and project overview are available side by side in the same interface, without switching between extension and terminal.

This distinction also explains why Nuxt DevTools was developed by Anthony Fu and the Nuxt team alongside the Vue browser extension, rather than as its replacement. Vue DevTools remains the right tool for framework wide questions about components and reactivity, while Nuxt DevTools specifically answers questions that only make sense in the context of a concrete Nuxt project with its file and module structure.

2. Activation and first steps in the panel

Nuxt DevTools has been active by default in dev mode since Nuxt 3.8, as long as the package is installed.

For older projects, npm install -D @nuxt/devtools plus the entry devtools: { enabled: true } in nuxt.config.ts is enough. The next time the dev server starts, a small floating Nuxt icon appears at the bottom edge of the screen, clicking it opens the full panel as an overlay over the running application.

Alternatively, Nuxt DevTools can also be opened as a standalone terminal tool via npx @nuxt/devtools@latest in a separate tab in standalone mode, handy for multi monitor setups or when the overlay would get in the way of the actual application content. Both variants read from the same data source and show identical information, the only difference is whether it renders as an overlay or as a separate window.

// nuxt.config.ts — enabling Nuxt DevTools explicitly
export default defineNuxtConfig({
  devtools: {
    enabled: true,
    // Opt in to the standalone timeline of build and HMR events
    timeline: {
      enabled: true,
    },
  },
})

// package.json — pinning the devtools version for the whole team
// "devDependencies": { "@nuxt/devtools": "^1.3.0" }

3. Module tab: understanding installed Nuxt modules

The Modules tab in Nuxt DevTools lists every active Nuxt module with its version, configuration source and a direct link to its documentation. In projects with ten or more modules, for example for SEO, image optimization, internationalization and authentication, this replaces tedious searching through package.json and scattered config files with a single, searchable overview right in the browser.

Particularly helpful is the module recommendation feature: Nuxt DevTools suggests matching community modules based on patterns it detects in the project, for example an image module when many unoptimized <img> tags are found. That reduces the need to manually search the Nuxt module directory for every new requirement, without installing anything automatically, the decision stays with the developer.

4. Component graph and auto-import origin

Nuxt relies heavily on automatic imports, for components, composables and utilities.

That is exactly what makes it hard in larger projects to trace where a given component or function is actually imported from. The Components tab in Nuxt DevTools visualizes this graph: every registered component with its file path, its auto-import rule, and, where applicable, the modules that additionally provide it.

This overview reliably surfaces naming conflicts, for instance when two modules accidentally register a component with the same name and Nuxt silently overwrites one of them.

Without Nuxt DevTools, such a conflict often stays unnoticed until wrong visual behavior shows up in production. The graph also shows which components render client side, server side, or as an island as part of Island Components.

For projects gradually migrating from an older setup with manual imports to full auto imports, the component graph is a helpful progress indicator: it immediately shows which components are already recognized through Nuxt conventions and which still need manual imports, without writing a separate migration script for it.

// components/ProductCard.vue — auto-registered, visible in DevTools graph
// No manual import needed anywhere in the project
export default defineComponent({
  name: 'ProductCard',
  props: {
    product: { type: Object, required: true },
  },
})

// Nuxt DevTools "Components" tab shows:
// - resolved file path
// - auto-import source (local vs. module-provided)
// - whether a naming collision was silently resolved

5. Inspecting server routes and Nitro endpoints

Nuxt 3 applications ship with Nitro, their own server layer, which automatically registers API routes under server/api.

The Server tab in Nuxt DevTools lists every detected route with its HTTP method, file path, and, when available, the most recently recorded requests including response time and status code. For debugging a Nuxt fullstack project, this often replaces opening the network tab and terminal log separately.

A concrete use case: an endpoint unexpectedly returns a 500, but only a generic error message shows up in the client network tab. In the Server tab of Nuxt DevTools, the same request can be traced with a full stack trace and the actual query parameters received, without adding extra logging to the code.

6. Assets, payload and build analysis

The Assets tab shows every static file in the public directory with file size and a preview, handy for spotting forgotten, oversized images that are accidentally shipped uncompressed. The Payload tab in turn shows the serialized state Nuxt transfers to the client during server side rendering, including that payload's size, a direct lever for reducing a page's initial load time.

For deeper performance analysis, Nuxt DevTools also integrates Vite build statistics: module count, build duration per plugin, and, when bundle analysis is enabled, a visual breakdown of chunk sizes. Anyone who notices the initial JavaScript payload is unexpectedly large usually finds the culprit import this way, without manually configuring a separate bundle analysis tool.

// Checking payload size impact directly from a page component
// Nuxt DevTools "Payload" tab shows the serialized state size per route
export default defineNuxtComponent({
  async asyncData() {
    // Large, unused fields inflate the SSR payload — DevTools flags this
    const { data } = await useFetch('/api/products', {
      // Only pick fields actually rendered, keep payload lean
      transform: (list) => list.map(({ id, name, price }) => ({ id, name, price })),
    })
    return { data }
  },
})

7. Custom panels and extending configuration

Nuxt DevTools is itself extensible.

Through the kit API addCustomTab, module authors can register their own panel in the DevTools UI, appearing right next to the Modules tab, Components tab and Server tab. Larger Nuxt modules such as Content or Image already use this to provide module specific diagnostic tools directly in the familiar DevTools context, instead of building a separate, standalone debug interface.

Teams also benefit from a look at the Config tab, which shows the fully resolved nuxt.config.ts, including every value that was overridden by modules or environment variables at runtime. That surfaces configuration mistakes that would otherwise only be found by manually debugging module order, for instance when a module loaded later silently overwrites a value set earlier.

8. Nuxt DevTools in production and in a team

By default, Nuxt DevTools is only active in development mode and is automatically removed from the production build, so no extra code or attack surface ends up in the live application. For teams with multiple developers, it is worth committing the enabled configuration in nuxt.config.ts rather than setting it only locally, so everyone on the team uses the same panels and the same version of Nuxt DevTools.

A sensible team workflow: when onboarding new developers, a short tour through the Modules tab, component graph and server routes often replaces hours of manually digging through the codebase. New team members understand within a few minutes, via Nuxt DevTools, which modules are active, how auto imports work and which server routes exist, knowledge that would otherwise only come from trial and error.

Another aspect for teams with strict security policies: since Nuxt DevTools runs exclusively locally inside the dev server and sends no data to external services, it raises none of the additional compliance questions that cloud based monitoring tools often bring up. For projects with sensitive customer data in the development environment, that is a meaningful difference compared to tools that send telemetry to third parties.

9. Nuxt DevTools compared to other tools

Nuxt DevTools does not directly compete with the Vue browser extension or with generic bundle analysis tools, but complements them with Nuxt specific knowledge. The following table places the most important tools by their respective focus.

In practice, Nuxt DevTools does not fully replace any of these tools, but it noticeably reduces daily context switching, because module, route and asset information is available directly in the same panel as the component graph, instead of being spread across several separate tools.

10. Summary

Nuxt DevTools brings module overview, component graph, server route inspector, asset browser and build analysis into a single, directly embedded panel, without a separate browser extension. For Nuxt 3 fullstack projects, this noticeably reduces the daily switching between terminal, network tab and editor, because most diagnostic information comes together in one place.

Nuxt DevTools is particularly valuable when onboarding new team members and when hunting silent conflicts, such as duplicated components or unexpectedly large SSR payloads. Committing its version through nuxt.config.ts ensures everyone on the team has the same view of the project, regardless of individual local settings.

11. FAQ: Nuxt DevTools