Top 50 Nuxt.js Interview Questions & Answers (2026)

Nuxt.js is a meta-framework built on top of Vue.js that provides a higher-level structure for building full-stack web applications. It offers features like server-side rendering (SSR), static site generation (SSG), file-based routing, auto-imports, and a built-in server engine called Nitro. Nuxt simplifies the configuration overhead of Vue applications by providing sensible defaults and a convention-over-configuration approach. It is often compared to Next.js (which is built on React), serving as the Vue ecosystem's equivalent for production-ready, SEO-friendly applications.

Vue.js is a UI library/framework for building reactive user interfaces, while Nuxt.js is a full-stack meta-framework built on top of Vue. Vue alone is a client-side rendering framework by default — you manage routing, state, and build configuration yourself. Nuxt adds file-based routing, SSR/SSG, auto-imports for components and composables, a built-in server with API routes, and integrations with modules like Pinia, i18n, and Nuxt Content. In short, Nuxt provides a complete opinionated application structure, whereas Vue is just the rendering layer.

Server-Side Rendering (SSR) means that the HTML for a page is generated on the server for each request and sent to the browser already populated with content. In Nuxt.js, SSR is enabled by default. When a user visits a URL, Nuxt's Nitro server executes Vue component code, fetches data, renders the component tree to HTML, and sends it to the browser. The browser then hydrates this HTML with JavaScript to make it interactive. SSR improves initial page load performance and is critical for SEO because search engine crawlers receive fully rendered HTML.

Static Site Generation (SSG) in Nuxt.js pre-renders all pages to static HTML files at build time rather than at request time. This is achieved using nuxt generate. The resulting HTML files can be deployed to any static hosting provider (Netlify, Vercel, GitHub Pages) without a Node.js server. SSG is ideal for content that doesn't change frequently — blogs, documentation, marketing sites. Nuxt 3 also supports ISR (Incremental Static Regeneration) through Nitro, allowing specific routes to revalidate and regenerate at configurable intervals.

Nuxt.js automatically creates routes based on the file structure inside the pages/ directory — no manual router configuration is needed. A file named pages/about.vue becomes the route /about. Nested folders create nested routes: pages/blog/index.vue becomes /blog. Dynamic segments use brackets: pages/posts/[id].vue becomes /posts/:id. Catch-all routes use [...slug].vue. This convention-based routing eliminates boilerplate and keeps the project structure self-documenting.

The official way to scaffold a new Nuxt 3 project is using npx nuxi@latest init my-app. This uses nuxi, the Nuxt CLI, to create a minimal project with the required structure. After scaffolding, you run cd my-app && npm install followed by npm run dev to start the development server. Nuxi also supports additional commands like nuxi add page about to generate pages, nuxi add component Header to generate components, and nuxi build to create a production build. You can optionally use the Nuxt starter templates on StackBlitz for instant online development.

The pages/ directory is a special directory in Nuxt.js where every .vue file automatically becomes a route in your application. Nuxt scans this directory and uses Vue Router under the hood to map files to URL paths. The pages/index.vue file maps to the root route /. The directory supports nested routes, dynamic parameters (e.g., [id].vue), optional parameters (e.g., [[slug]].vue), and catch-all routes. If your app doesn't need multiple pages, you can omit this directory and use only app.vue.

nuxt.config.ts is the central configuration file for a Nuxt.js application. It is written in TypeScript and allows you to configure virtually every aspect of the framework: registering modules (e.g., @nuxtjs/tailwindcss), setting runtime config for environment variables, defining head metadata (title, meta tags), configuring Vite or Webpack options, enabling experimental features, adding CSS files, configuring the Nitro server, and setting up i18n. The config is strongly typed, providing auto-completion in your editor.

Layouts in Nuxt.js are reusable page wrappers stored in the layouts/ directory. They wrap page components and provide a consistent shell — like a navbar, sidebar, or footer — across multiple pages. The default layout is layouts/default.vue and is applied automatically to all pages unless overridden. A page can specify a different layout using definePageMeta({ layout: 'blog' }), which then uses layouts/blog.vue. Layouts use the <slot /> tag to render the current page content within the wrapper structure.

<NuxtLink> is Nuxt's wrapper around Vue Router's <RouterLink> and should be used for internal navigation within your application. It enables client-side navigation (SPA-style page transitions without full page reloads), automatically prefetches linked pages when they appear in the viewport, and handles active link class styling. A plain <a> tag causes a full browser page reload, losing the SPA state and being significantly slower. Use <NuxtLink> for any internal route and plain <a> only for external links.

Composables in Nuxt.js are reusable functions that encapsulate stateful logic using Vue's Composition API. They are stored in the composables/ directory and are auto-imported throughout the application without explicit import statements. Nuxt also provides built-in composables like useAsyncData, useFetch, useState, useRoute, useRouter, useRuntimeConfig, and useCookie. Composables make it easy to share logic between components while keeping it reactive and SSR-compatible. The naming convention is use + PascalCase (e.g., useUser).

useAsyncData is a Nuxt composable used to fetch data asynchronously in a way that is compatible with both SSR and CSR. It takes a unique key and an async function, executes the function on the server during SSR, serializes the result into the page payload, and reuses that data on the client during hydration — preventing a duplicate network request. The return value includes data, pending, error, and refresh refs. Example: const { data } = await useAsyncData('posts', () => $fetch('/api/posts')). The unique key ensures data is deduplicated across server and client.

useFetch is a convenience wrapper around useAsyncData and Nuxt's $fetch utility that combines both in a single composable specifically designed for HTTP requests. It automatically generates the cache key from the URL and options, making it simpler than useAsyncData for direct API calls. Usage: const { data, pending, error } = await useFetch('/api/users'). It supports options like method, body, headers, query, lazy, and watch. The lazy option defers the fetch until after navigation, useful for non-critical data.

Nuxt.js automatically imports Vue components from the components/ directory, meaning you can use any component in your templates without writing import statements. The component name is derived from its file path: components/ui/Button.vue becomes <UiButton />. Nuxt also supports lazy loading of components by prefixing with Lazy: <LazyModal /> is only loaded when it appears in the DOM. This auto-import system reduces boilerplate significantly and works with nested directories, following a consistent naming convention based on folder structure.

Plugins in Nuxt.js are files stored in the plugins/ directory that run before the Vue application is mounted. They are used to integrate third-party libraries, provide global utilities, register global Vue components, or extend the Nuxt application context. Plugins can be run only on the client (suffix .client.ts), only on the server (.server.ts), or on both. A plugin exports a default function using defineNuxtPlugin(). The provide helper inside plugins makes utilities available globally via useNuxtApp().$myHelper.

The public/ directory contains static assets that are served directly at the root URL without any processing by Vite or Nitro. Files placed here are accessible as-is: a file at public/logo.png is available at /logo.png. This is the right place for robots.txt, favicon.ico, static images, and other files that don't need bundling or transformation. It differs from assets/, which is processed by Vite — assets there can be imported in components and have their URLs hashed for cache busting. Use public/ when you need a stable, predictable URL.

Middleware in Nuxt.js are functions that run before navigating to a particular route. They can be used for authentication checks, redirects, analytics, or any pre-navigation logic. There are three types: inline middleware (defined directly in definePageMeta), named middleware (files in the middleware/ directory referenced by name), and global middleware (files in middleware/ with a .global.ts suffix that run on every route). Server middleware, stored in server/middleware/, runs on the Nitro server side and intercepts all API requests. Middleware receives the to and from route objects.

The server/ directory enables Nuxt.js to function as a full-stack framework by providing a built-in server powered by Nitro. Inside it, server/api/ contains API route handlers — a file at server/api/users.get.ts handles GET requests to /api/users. The HTTP method is specified in the filename (.get, .post, .put, .delete). server/middleware/ contains server-side middleware, and server/utils/ holds utilities auto-imported within the server context. This makes Nuxt capable of replacing a separate Express or Fastify backend for many use cases.

Nuxt.js manages environment variables through runtime config defined in nuxt.config.ts. Public variables (safe to expose to the client) go under runtimeConfig.public, while private variables (server-only secrets) go under runtimeConfig directly. These are populated at runtime from your .env file — Nuxt automatically maps NUXT_PUBLIC_API_URL to runtimeConfig.public.apiUrl. On the client and server, you access them via const config = useRuntimeConfig(). This approach is safer than using import.meta.env directly, as it prevents accidentally leaking server secrets to the browser bundle.

Dynamic routes in Nuxt.js are created by wrapping a filename segment in square brackets. For example, pages/posts/[id].vue matches /posts/1, /posts/hello, etc. Inside the component, you access the parameter via const route = useRoute(); route.params.id. You can have multiple dynamic segments: pages/[category]/[slug].vue. For catch-all routes, use [...slug].vue, which matches any number of path segments. Optional catch-all routes use [[...slug]].vue and also match the route with no trailing segments. For SSG, you must define which dynamic routes to pre-render using nitro.prerender.routes or the routeRules config.

Both composables fetch data with SSR support and deduplication, but they differ in scope. useFetch is a shorthand specifically for HTTP requests — it wraps useAsyncData with $fetch and auto-generates the cache key from the URL. useAsyncData is more general-purpose — its async handler can be any async operation (database query, file read, complex computation), not just HTTP. Use useFetch for direct API calls for brevity; use useAsyncData when you need a custom key, custom logic, or need to call multiple sources in one composable. Both return { data, pending, error, refresh, execute }.

Authentication in Nuxt.js is commonly implemented using the nuxt-auth-utils or Sidebase nuxt-auth module. The pattern involves: (1) creating a server API route (e.g., server/api/auth/login.post.ts) that validates credentials and sets a secure HTTP-only cookie with a session token; (2) using useCookie or useAuthState to access the session on the client; (3) adding a global middleware in middleware/auth.global.ts that checks authentication and redirects unauthenticated users. Alternatively, nuxt-auth-utils provides setUserSession() and getUserSession() server utilities with built-in sealed cookie sessions.

useState is a Nuxt composable that creates SSR-safe shared reactive state that persists across components and between server and client. Unlike Vue's ref(), useState is serialized in the server response payload and rehydrated on the client, ensuring consistent state without a flash. It takes a unique key and optional initializer: const count = useState('count', () => 0). Multiple components using the same key share the same state. For complex state management, Pinia (the official Vue state management library) integrates seamlessly with Nuxt via the @pinia/nuxt module and offers DevTools support, actions, and getters.

Nuxt.js provides first-class SEO support through the useHead() and useSeoMeta() composables, which set <head> metadata reactively. useSeoMeta({ title: 'My Page', description: '...' }) sets both standard meta tags and Open Graph tags in one call. You can configure global defaults in nuxt.config.ts under app.head and override them per-page with useHead(). Since Nuxt SSR renders complete HTML server-side, search engine crawlers receive fully populated meta tags. The @nuxtjs/sitemap and @nuxtjs/robots modules add sitemap.xml and robots.txt generation automatically.

The Nuxt Content module (@nuxt/content) is a file-based CMS that lets you write content in Markdown, MDC, YAML, CSV, or JSON files stored in the content/ directory. It parses these files and provides a query API (similar to a database query builder) to fetch and filter content. The queryContent() composable supports filtering, sorting, limiting, and navigating through content. The <ContentDoc /> and <ContentRenderer /> components render Markdown with custom Vue components via the MDC syntax. It's ideal for documentation sites, blogs, and any content-heavy application that benefits from version-controlled Markdown files.

API routes are created as files inside server/api/. The file name determines the URL path and HTTP method. A file at server/api/users.get.ts handles GET /api/users. Each file exports a default function wrapped in defineEventHandler(): export default defineEventHandler(async (event) => { return { users: [] } }). You can read request body with await readBody(event), query params with getQuery(event), and headers with getHeader(event, 'authorization'). Nitro automatically serializes returned objects as JSON. Utility functions in server/utils/ are auto-imported in the server context, enabling clean separation of database logic from route handlers.

definePageMeta() is a compile-time macro used within page components to set metadata that Nuxt's routing system processes — it's not a regular composable. It accepts layout to specify which layout wraps the page, middleware to define route guards, pageTransition for animations, and keepalive to cache the component instance. Layout can also be configured globally in nuxt.config.ts via app.layoutTransition. The key distinction is that definePageMeta is per-page configuration evaluated at route time, while the layout component itself is a structural wrapper that uses <slot />. You can also change the layout dynamically using setPageLayout('name').

Nuxt.js provides a special error.vue file at the root of the project that serves as the global error page. This component receives an error prop containing the status code and message. For different status codes, you can render different content: a 404 page for missing routes, a 500 page for server errors. You can throw errors in page components or server routes using throw createError({ statusCode: 404, statusMessage: 'Not Found' }). To clear an error and redirect, use the clearError({ redirect: '/' }) utility. For catching errors within component render, Nuxt also exposes the onErrorCaptured Vue hook and the NuxtErrorBoundary component for granular error boundaries.

Nitro is the server engine powering Nuxt 3. It is a cross-platform, universal server framework that handles routing, server-side rendering, API routes, and deployment. Nitro's standout feature is its universal deployment capability — it compiles the Nuxt server to work on Node.js, Deno, Cloudflare Workers, AWS Lambda, Vercel Edge Functions, and other runtimes with zero configuration changes. It includes a file-system routing layer for server routes, a built-in cache API for response caching, a key-value storage abstraction, and support for ISR (Incremental Static Regeneration). Nitro is also available as a standalone framework independent of Nuxt.

Nuxt.js performs automatic code splitting by generating a separate JavaScript chunk for each page in the pages/ directory. This means users only download the code for the page they are currently viewing, reducing the initial bundle size. Nuxt uses Vite (or optionally Webpack) for bundling, which leverages native ES module dynamic imports. Nuxt's component lazy loading feature further reduces bundle size: prefixing a component with Lazy (e.g., <LazyHeavyComponent />) converts it to a dynamic import. You can also manually split code using Vue's defineAsyncComponent(). The Nuxt DevTools show bundle analysis to help identify large chunks.

app.vue is the root component of a Nuxt 3 application. If you have a pages/ directory, app.vue should contain <NuxtPage /> to render the current page. If you use layouts, it should include <NuxtLayout><NuxtPage /></NuxtLayout>. If your app is a single page without routing, app.vue can contain everything and you can omit the pages/ directory entirely. It's the right place to add global CSS imports, top-level error handling with <NuxtErrorBoundary>, and application-wide logic that runs once. The app.vue file is optional — if absent, Nuxt uses a default one.

Internationalization in Nuxt.js is best handled with the @nuxtjs/i18n module, which integrates vue-i18n with Nuxt's routing system. After installing, you configure it in nuxt.config.ts with the supported locales and default locale. Translation strings are stored in JSON or YAML files in a locales/ directory. The module automatically prefixes routes with locale codes (e.g., /en/about, /fr/about). Composables like useI18n() provide t() for translations and locale for the current language. Lazy-loading of locale files prevents loading all translations upfront. SEO is handled via hreflang link tags generated automatically.

Nuxt DevTools is an official browser-based development tool included in Nuxt 3 (enable with devtools: { enabled: true } in config). It provides a visual interface accessible at /__nuxt_devtools__/ with tabs for: Pages (all routes), Components (component tree with props), Imports (auto-imported composables and utilities), Modules (installed modules), Assets (static files), Plugins, Hooks, and a built-in VS Code extension for opening components directly. It also includes a bundle analyzer, timeline for performance profiling, and component inspector for clicking elements in the browser to jump to source. It's invaluable for understanding what Nuxt generates at runtime.

Nuxt provides image optimization through the @nuxt/image module. It offers the <NuxtImg> and <NuxtPicture> components that automatically resize, convert to modern formats (WebP, AVIF), and lazy-load images. Images can be served through various providers: local (using Sharp for on-demand resizing), Cloudinary, Imgix, Vercel, IPX (a built-in image server). You configure the default provider and presets in nuxt.config.ts. <NuxtImg src="/hero.jpg" width="800" height="400" format="webp" /> generates the correct srcset and serves the right size to the right device. The module also handles responsive images and the loading="lazy" attribute automatically.

useRuntimeConfig() is a composable that provides access to runtime configuration variables defined in nuxt.config.ts under the runtimeConfig key. It is the recommended way to access environment variables in Nuxt instead of using process.env directly. On the server, it returns both private and public config. On the client, only runtimeConfig.public values are accessible for security reasons. Nuxt automatically maps environment variables to runtime config: setting NUXT_PUBLIC_API_BASE in .env overrides runtimeConfig.public.apiBase at runtime without rebuilding, enabling dynamic configuration in containerized deployments.

Pinia integrates with Nuxt through the @pinia/nuxt module. After installing both packages and adding '@pinia/nuxt' to the modules array in nuxt.config.ts, stores defined in the stores/ directory are auto-imported. You define a store with defineStore('user', () => { const name = ref(''); return { name } }). The key Nuxt-specific consideration is SSR safety: since multiple requests share the server environment, each request must get its own store instance. Pinia handles this automatically with Nuxt by creating a fresh store per request. State defined via useState or Pinia is serialized into the <script id="__NUXT_DATA__"> tag for hydration.

These are two distinct types of middleware serving different purposes. Route middleware (in middleware/) runs on the Vue Router level — it executes during client-side navigation and SSR page rendering, has access to the to/from route objects, and is used for auth guards, redirects, and route-level logic. Server middleware (in server/middleware/) runs on the Nitro HTTP server level for every incoming request — before routing — and has access to the raw HTTP event. Use server middleware for CORS headers, request logging, rate limiting, and API request processing. Server middleware never runs on the client; route middleware can run on both server and client.

Nuxt.js supports lazy loading at multiple levels. For components, prefix the component name with Lazy in the template: <LazyModal v-if="showModal" /> — this generates a dynamic import so the component's code is only loaded when it's first rendered. For images, <NuxtImg loading="lazy" /> uses native browser lazy loading. For routes, Nuxt already splits each page into its own chunk automatically. For data, useFetch(url, { lazy: true }) defers the fetch until after navigation instead of blocking it. You can also manually lazy-load components using Vue's defineAsyncComponent() with custom loading and error states.

Universal rendering in Nuxt involves two phases. First, on a server request, Nuxt runs the Vue component tree in a Node.js/Nitro environment: it executes useAsyncData/useFetch handlers, renders components to HTML string using @vue/server-renderer, serializes the fetched data into a __NUXT_DATA__ script tag, and sends the complete HTML. Second, when the browser receives this HTML, it appears immediately (fast FCP). Then the Vue hydration process runs: Vue loads the client bundle, re-creates the component tree in memory, and "claims" the existing DOM nodes by attaching event listeners without re-rendering. The serialized server data prevents duplicate API calls. If the server-rendered DOM doesn't match what the client would render (hydration mismatch), Vue logs a warning and falls back to client-rendering that subtree, which is why SSR-unsafe operations (like window access) must be guarded with import.meta.client.

Performance optimization in Nuxt spans multiple layers: (1) Lazy-load components with the Lazy prefix and useFetch({ lazy: true }) for non-critical data. (2) Use route-level code splitting which Nuxt does automatically, and further analyze bundles with nuxt analyze or Rollup visualizer. (3) Enable Nitro's cache layer using routeRules: { '/api/**': { cache: { maxAge: 60 } } } in nuxt.config.ts to cache API responses. (4) Use @nuxt/image with proper providers for image optimization. (5) Prerender static routes with routeRules: { '/about': { prerender: true } } for CDN delivery. (6) Configure Brotli/gzip compression via Nitro's compression plugin. (7) Use Pinia with careful store design to avoid unnecessary re-renders. (8) Profile with Chrome DevTools and Nuxt DevTools' timeline tab.

Server components and island components are Nuxt's implementation of partial hydration — a technique to reduce the JavaScript sent to the browser. A component suffixed with .server.vue (e.g., components/HeavyChart.server.vue) renders only on the server and sends pure HTML with zero client-side JavaScript. An island component (accessed via <NuxtIsland component="MyComponent" />) renders server-side and can be refreshed independently via a dedicated API endpoint without a full page reload. This is analogous to Astro's island architecture and React Server Components. The benefit is a massively reduced Time to Interactive (TTI) for content-heavy pages where most content is static and only a few interactive widgets need hydration.

A custom Nuxt module is a function that receives the resolved Nuxt config and has access to Nuxt hooks and the Nuxt Kit utility library. You define it using defineNuxtModule({ setup(options, nuxt) { ... } }). Inside setup, you can use Nuxt Kit APIs: addPlugin() to inject plugins, addComponent() to register components, addImports() to add auto-imported composables, addServerHandler() to add Nitro API routes, and addTemplate() to generate virtual files. You hook into Nuxt's build lifecycle with nuxt.hook('build:before', handler). Local modules can live in the modules/ directory (auto-registered) or be published as npm packages with the nuxt-module tag.

Edge rendering means running the Nuxt server at CDN edge nodes worldwide, closer to users, for minimal latency. Nitro's universal build target enables this — by setting nitro: { preset: 'cloudflare-pages' } or 'vercel-edge', Nuxt compiles the entire server (SSR logic, API routes, middleware) into a format compatible with the V8 Isolates environment used by Cloudflare Workers and Vercel Edge Runtime. Edge environments have limitations: no native Node.js modules (no fs, crypto), restricted cold start budget, and limited memory. Nuxt abstracts most of these differences, but database connections must use HTTP-based edge-compatible clients (Turso libSQL, Neon serverless driver, Upstash Redis). Edge rendering is ideal for personalized content that needs SSR with global low latency.

Nuxt Layers are a composable architecture feature where multiple Nuxt applications or packages can be stacked, with each layer contributing its own pages, components, composables, server routes, and config. Layers are defined in nuxt.config.ts under extends: ['./base-layer', 'npm:my-layer-package']. The final application merges all layers, with closer layers overriding deeper ones. This enables powerful patterns: a design system layer providing shared components, a CMS layer providing content-fetching composables, or a monorepo base layer with shared utilities. Each layer is itself a valid Nuxt project. Layers can be local directories, Git repositories, or npm packages, making them the Nuxt equivalent of platform-level code sharing.

Nuxt 3 supports WebSockets through Nitro's WebSocket event handlers (available from Nuxt 3.12+). You create a WebSocket handler in server/routes/_ws.ts using defineWebSocketHandler({ open(peer) { ... }, message(peer, message) { ... }, close(peer) { ... } }). Nitro uses crossws under the hood, which abstracts WebSocket implementations across Node.js (uWebSockets.js), Bun, Deno, and Cloudflare Durable Objects. On the client, you connect using the native WebSocket API or Nuxt's useWebSocket composable from VueUse. For production scaling (multiple server instances), you need a shared pub/sub layer like Redis or a Cloudflare Durable Object to broadcast messages across instances, since WebSocket connections are tied to specific server nodes.

useRequestHeaders() is an SSR-specific Nuxt composable that retrieves incoming HTTP request headers within the server rendering context. It's primarily used for cookie forwarding during SSR — when your Nuxt server makes internal API calls (e.g., useFetch('/api/profile')), the user's authentication cookies must be forwarded so the API can identify the user. Without this, server-side fetches would be unauthenticated. Example: const headers = useRequestHeaders(['cookie']); const { data } = await useFetch('/api/user', { headers }). It returns an empty object on the client side (where request headers don't exist), making it safe to use in universal code. This composable only works during SSR; in client-only contexts it has no effect.

Streaming SSR allows the server to send HTML to the browser in chunks as it's generated, rather than waiting for the entire page to render before sending the first byte. This significantly improves Time to First Byte (TTFB) for pages with slow data fetching. Nuxt 3 supports streaming via Nitro's experimentalStreaming option (configurable in nuxt.config.ts). When enabled, Nuxt uses Vue's renderToWebStream() or renderToNodeStream() instead of renderToString(). The browser can start parsing and rendering the initial HTML (navigation, layout) while slower data fetches complete. Suspense boundaries are used to define which parts can stream independently. The Nuxt NuxtLoadingIndicator component complements this by showing progress during navigation.