Vue.js meta-framework with SSR, static site generation, auto-imports, and file-based routing. The Vue equivalent of Next.js.
Websites Using Nuxt
No websites detected yet. Analyze a website to contribute data.
What Is Nuxt?
Nuxt is the meta-framework for Vue.js: a higher-level framework that takes the Vue UI library and adds the production plumbing real websites need, including server-side rendering (SSR), static-site generation (SSG), file-based routing, and automatic code-splitting. If you want the short answer, Nuxt is to Vue what Next.js is to React. It turns Vue from a client-side library into a full-stack framework that can render pages on the server, pre-build them at deploy time, or hydrate them in the browser, all from a single codebase.
Nuxt is open source and maintained by the Nuxt core team alongside a large community. The project's own documentation positions it as a framework for building "full-stack web applications and websites with Vue," and its rendering and routing conventions are documented publicly at nuxt.com. Exact market-share figures vary by source and detection methodology, so treat any single percentage with caution. What technology-detection surveys consistently report is that Nuxt sits among the most widely used Vue-based frameworks, well behind React-centric tools like Next.js in raw site counts but firmly established as the default choice for teams that have already committed to Vue.
The practical reason Nuxt appears so often when you analyze a Vue site is that building SSR, routing, and bundling by hand is tedious and error-prone. Nuxt packages those concerns behind sensible conventions, so most Vue projects that need SEO-friendly server rendering or static export reach for Nuxt rather than wiring everything up themselves.
How Nuxt Works
Nuxt sits on top of Vue and orchestrates how your application is rendered and delivered. The current generation, Nuxt 3 and later, is built on Vue 3, the Vite build tool, and a server engine called Nitro.
The starting point is file-based routing. Instead of declaring routes in a configuration file, you create .vue files inside a pages/ directory, and Nuxt generates the router for you. A file at pages/about.vue becomes the /about route; a file at pages/blog/[slug].vue becomes a dynamic route that matches /blog/anything. This convention is one of the clearest behavioral fingerprints of a Nuxt site.
The second pillar is rendering mode. Nuxt can run in several modes, and the mode determines what a visitor's browser actually receives:
- Universal (SSR): Pages are rendered to HTML on the server for each request, then hydrated in the browser so they become interactive. This is the default and the most SEO-friendly mode.
- Static (SSG): Pages are pre-rendered to HTML at build time and served as static files, ideal for content that does not change per request.
- Client-side (SPA): The server sends a minimal HTML shell and the application boots entirely in the browser.
- Hybrid: Different routes use different rendering rules, configured per route, so a marketing homepage can be static while a dashboard is server-rendered.
Under the hood, Nitro is the server engine that makes this portability possible. Nitro builds a deployment-agnostic output that can run on Node.js, Deno, or edge platforms such as Cloudflare Workers and Vercel Edge Functions. It also powers Nuxt's server/ directory, where you can define API routes and server middleware that live in the same project as your frontend.
The third pillar is hydration. When Nuxt renders a page on the server, it serializes the data and state the page needs into the HTML so the browser can "resume" the application without re-fetching everything. This serialized payload is injected inline into the page, which is both how Nuxt achieves fast first paint and, conveniently, one of the strongest detection signals (more on that below).
Nuxt rounds this out with auto-imports (Vue composables and your own components become available without manual import statements), a module ecosystem for pre-packaged features like image optimization and content management, and a build pipeline that emits hashed asset files into a /_nuxt/ directory.
Data fetching deserves its own mention because it shapes both behavior and detection. Nuxt provides composables such as useFetch and useAsyncData that run on the server during the initial render, serialize their results into the page, and then reuse that data in the browser rather than re-requesting it. This avoids the classic SSR pitfall where a page fetches the same data twice, once on the server and again after hydration. The serialized result is part of the inline payload that makes Nuxt recognizable.
It is worth distinguishing the two major generations you will encounter in the wild. Nuxt 2 was built on Vue 2 and webpack, and it is the version most strongly associated with a window.__NUXT__ global. Nuxt 3 moved to Vue 3, Vite, and the Nitro engine, changing build internals and some serialization details while keeping the same conventions: the pages/ directory, the /_nuxt/ asset path, and an inline hydration payload. When you detect Nuxt, you are usually identifying these durable conventions rather than a specific version, though the exact shape of the inline data can hint at which generation you are looking at.
How to Tell if a Website Uses Nuxt
Because Nuxt renders on the server and ships a predictable asset structure, it leaves several reliable fingerprints. Here are the signals to look for and the tools that surface them.
1. The inline hydration payload. Nuxt injects its hydration data into the page, and on Nuxt 2 sites this is famously a global JavaScript object. Viewing the page source and searching for __NUXT__ (often assigned as window.__NUXT__) is one of the most direct confirmations. Nuxt 3 changed the serialization details, but the page still ships an inline state payload tied to a Nuxt app root, so the presence of a hydration script alongside the other signals below is a strong indicator.
2. The /_nuxt/ asset path. Nuxt emits its compiled JavaScript and CSS into a /_nuxt/ directory with hashed filenames. Seeing <script> or <link> tags pointing at /_nuxt/entry.[hash].js or similar is a near-definitive fingerprint, because that path is a Nuxt convention rather than a generic bundler default.
3. Vue markers. Because Nuxt is Vue underneath, you will also see Vue's own footprints: data-v-[hash] attributes on elements (the marker Vue's scoped-CSS compiler adds), an app mount point such as <div id="__nuxt"> or <div id="__app">, and the runtime behavior of a Vue single-page app once hydrated.
4. Generator and meta hints. Some Nuxt sites emit a <meta name="generator" content="Nuxt ..."> tag, which states the framework outright. This is optional and can be removed, so its absence does not rule Nuxt out, but its presence is conclusive.
5. Tooling. You rarely need to read raw HTML by hand:
- View Source (right-click then "View Page Source") reveals the inline
__NUXT__/hydration payload, the/_nuxt/script tags, and any generator meta tag. - Browser DevTools (the Network and Elements tabs) shows the
/_nuxt/requests as the page loads and thedata-v-attributes in the live DOM. - Wappalyzer and similar technology-detection extensions identify Nuxt (and Vue) automatically and display them in a single click.
- A server-side analyzer such as StackOptic inspects the delivered HTML and headers without you needing to open DevTools at all.
If you want the broader methodology behind framework fingerprinting, see how to check if a website uses React, Vue, or Angular and how to check what JavaScript libraries a website uses.
Key Features
Nuxt's feature set is what justifies adopting a meta-framework rather than plain Vue:
- Multiple rendering modes (SSR, SSG, SPA, and hybrid) selectable per route.
- File-based routing that derives the router from the
pages/directory structure, including dynamic and nested routes. - Nitro server engine that deploys to Node, edge runtimes, and serverless platforms from one build, with built-in API routes via the
server/directory. - Auto-imports for Vue composables, Nuxt utilities, and your own components, reducing boilerplate.
- Data fetching composables such as
useFetchanduseAsyncDatathat work seamlessly across server and client and avoid double-fetching on hydration. - A module ecosystem for image optimization, content/Markdown handling, internationalization, SEO metadata, and more, installable with minimal configuration.
- Automatic code-splitting so each route ships only the JavaScript it needs.
- First-class SEO controls through a metadata API for titles, meta tags, and structured data.
Pros and Cons
| Strengths | Trade-offs |
|---|---|
| Excellent SEO via server rendering and static export | Adds framework complexity over plain Vue |
| Convention-over-configuration reduces boilerplate | SSR/hybrid modes require a Node or edge host, not just static files |
| Deploy anywhere via the Nitro engine | Auto-imports can feel "magical" and obscure where code comes from |
| Strong, well-documented data-fetching story | Smaller ecosystem and hiring pool than React/Next.js |
| Hybrid rendering lets one app mix static and dynamic routes | Major-version migrations (e.g. Nuxt 2 to 3) can be involved |
For most Vue teams, the trade-offs are acceptable: the productivity and SEO gains outweigh the added abstraction, especially for content-heavy or marketing sites where server rendering matters.
Nuxt vs Alternatives
Nuxt competes with other meta-frameworks. The right comparison depends on which UI library you have committed to and how much you need server rendering.
| Framework | UI library | Rendering | Best for |
|---|---|---|---|
| Nuxt | Vue | SSR, SSG, SPA, hybrid | Vue teams needing SSR/SSG and conventions |
| Next.js | React | SSR, SSG, ISR, RSC | React teams; largest ecosystem |
| SvelteKit | Svelte | SSR, SSG, SPA | Teams wanting minimal runtime and small bundles |
| Gatsby | React | Primarily SSG | Content sites with a build-time data layer |
| Plain Vue + Vite | Vue | SPA (manual SSR) | Apps that do not need SSR or want full control |
If you are weighing the React side of this table, the Next.js technology profile covers the closest equivalent to Nuxt in the React world. The fundamental split is library choice: pick Nuxt because you want Vue, and pick Next.js because you want React. Both deliver comparable rendering capabilities.
Use Cases
Nuxt fits a wide range of projects, but it shines in a few specific scenarios:
- Marketing and content sites that need fast first paint and clean server-rendered HTML for SEO, often using static generation for most pages.
- E-commerce storefronts where product pages must be indexable and load quickly, and where hybrid rendering lets dynamic cart/account routes coexist with static catalog pages.
- Documentation and blogs, frequently paired with the Nuxt Content module to render Markdown with a type-safe data layer.
- Full-stack applications that want frontend and backend (API routes) in one repository deployed to an edge or serverless platform.
- Progressive web apps and dashboards that start server-rendered for SEO and then behave like a single-page app after hydration.
A useful way to read these use cases is by asking what rendering mode each implies. A marketing or documentation site usually leans static, pre-building pages so they can be served straight from a CDN. An e-commerce or membership site usually leans universal or hybrid, server-rendering the pages that must be fresh while statically generating the catalog. A heavily interactive internal tool might even run closer to a single-page app, server-rendering only the initial shell. This is why two Nuxt sites can deliver very different first responses: the framework is the same, but the configured rendering strategy differs. When you detect Nuxt on a site, checking whether the initial HTML is fully populated (suggesting SSR or SSG) or nearly empty (suggesting SPA mode) tells you a great deal about how that particular project is configured.
If you are auditing an unfamiliar site and want to know its full stack rather than just the framework, the workflow in how to find out what technology a website uses walks through combining framework, hosting, and analytics signals.
Want to identify Nuxt and the rest of a site's stack in seconds? Analyze any URL with StackOptic.
Frequently Asked Questions
Is Nuxt the same as Vue?
No. Vue is the underlying UI library that handles components and reactivity. Nuxt is a framework built on top of Vue that adds server-side rendering, routing, build configuration, and deployment tooling. Every Nuxt site is a Vue site, but not every Vue site uses Nuxt.
How can I tell Nuxt from a plain Vue app?
Both share Vue fingerprints like data-v- attributes. The differentiators are Nuxt-specific: an inline __NUXT__/hydration payload in the page source, assets served from a /_nuxt/ directory, a <div id="__nuxt"> mount point, and sometimes a Nuxt generator meta tag. A plain Vue single-page app usually ships a near-empty HTML shell with a generic bundle path and no server-rendered content.
Does Nuxt always render on the server?
Not necessarily. Universal (SSR) mode is the default, but Nuxt can also generate fully static sites, run as a client-side single-page app, or mix modes per route in hybrid configuration. Two Nuxt sites can therefore deliver very different initial HTML depending on how they are configured.
Can detection tools be wrong about Nuxt?
They can. If a site has removed the generator meta tag and you only glance at the rendered DOM, you might see Vue but miss Nuxt. Conversely, a heavily customized build could rename asset paths. The most reliable approach is to combine several signals, the inline payload, the /_nuxt/ path, and Vue markers, rather than relying on any single one.
Is Nuxt good for SEO?
Yes, that is one of its main reasons for existing. Because Nuxt can render complete HTML on the server or pre-build it as static files, search engines and AI crawlers receive fully formed content rather than an empty shell that requires JavaScript execution. This is a meaningful advantage over client-only Vue apps for content that needs to rank.