---
title: "Nuxt 3.4"
description: "Nuxt 3.4.0 is the latest release of Nuxt 3, bringing exciting new features, including support for the View Transitions API, transferring rich JavaScript payloads from server to client - and much more."
canonical_url: https://nuxt.com/blog/v3-4
last_updated: 2026-04-15
---

# Nuxt 3.4

> Nuxt 3.4.0 is the latest release of Nuxt 3, bringing exciting new features, including support for the View Transitions API, transferring rich JavaScript payloads from server to client - and much more.

## 🪄 View Transitions API Support

<article-video cloudinary="v1681229056/nuxt3/nuxt-view-transitions_cruvma">



</article-video>

You can check a demo on [https://nuxt-view-transitions.surge.sh](https://nuxt-view-transitions.surge.sh) and the [source on StackBlitz](https://stackblitz.com/edit/nuxt-view-transitions).

You may have noticed that Chromium-based browsers now ship a new web platform API: the [**View Transitions API**](https://developer.chrome.com/docs/web-platform/view-transitions/). This is an exciting new ability for native browser transitions which (among other things) have the ability to transition between unrelated elements on different pages.

Nuxt now ships with an experimental implementation, which will be under active development during the v3.4 release cycle. See the known issues in the [linked PR](https://github.com/nuxt/nuxt/pull/20092).

```ts
export default defineNuxtConfig({
  experimental: {
    viewTransition: true
  }
})
```

## ✨ Payload Enhancements

We've merged a **significant change to how Nuxt handles payloads** (under an experimental flag). Payloads are used to send data from the server to the client when doing server-side rendering and avoid double data-fetching during the hydration phase.

```ts [nuxt.config.ts]
export default defineNuxtConfig({
  experimental: {
    renderJsonPayloads: true
  }
})
```

With this new option enabled, this now means that **various rich JS types are supported out-of-the-box**: regular expressions, dates, Map and Set and BigInt as well as NuxtError - and Vue-specific objects like `ref`, `reactive`, `shallowRef` and `shallowReactive`.

You can find [an example](https://github.com/nuxt/nuxt/blob/main/test/fixtures/basic/pages/json-payload.vue) in our test suite.

This is all possible due to [Rich-Harris/devalue#58](https://github.com/Rich-Harris/devalue/pull/58). For a long time, Nuxt has been using our own fork of devalue owing to issues serialising Errors and other non-POJO objects, but we now have transitioned back to the original.

You can even register your own custom types with a new object-syntax Nuxt plugin:

```ts [plugins/custom-payload-type.ts]
export default definePayloadPlugin(() => {
  definePayloadReducer('BlinkingText', data => data === '<original-blink>' && '_')
  definePayloadReviver('BlinkingText', () => '<revivified-blink>')
})
```

You can read more about how this works [here](https://github.com/rich-harris/devalue#custom-types).

**Note**: this only affects payloads of the Nuxt app, that is, data stored within `useState`, returned from `useAsyncData` or manually injected via `nuxtApp.payload`. It does not affect data fetched from Nitro server routes via `$fetch` or `useFetch` although this is one area I am keen to explore further.

Preliminary testing shows a significant speed-up: **25% faster in total server response time** for a very minimal app with a large JSON payload, but I'd urge you to run your own tests and share the results with us.

As mentioned, we're merging this behind a flag so we can test this broadly and gather feedback on the new approach. The most significant potential change is that the payload is now no longer available on `window.__NUXT__` immediately. Instead, we now need to initialise the Nuxt app to parse the payload so any code that accesses `__NUXT__` will need to be run in a plugin or later in the Nuxt app lifecycle. Please feel free to raise an issue if you foresee or encounter issues in your projects.

## 🎁 Object-syntax Nuxt plugins

We now support object-syntax Nuxt plugins for better control over plugin *order* and easier registration of hooks.

```ts [plugins/my-plugin.ts]
export default defineNuxtPlugin({
  name: 'my-plugin',
  enforce: 'pre', // or 'post'
  async setup (nuxtApp) {
    // this is the equivalent of a normal functional plugin
  },
  hooks: {
    // You can directly register Nuxt app hooks here
    'app:created'() {
      const nuxtApp = useNuxtApp()
      //
    }
  }
})
```

In future we plan to enable build optimizations based on the metadata you pass in your Nuxt plugins.

## 🛠️ Easier Devtools Configuration

It's even easier to enable Nuxt DevTools in your project: just set `devtools: true` in your `nuxt.config.ts` file to enable devtools.

```ts [nuxt.config.ts]
export default defineNuxtConfig({
  devtools: true
})
```

If it's not already installed, Nuxt will prompt to install it locally. This means you no longer need to have Nuxt DevTools enabled globally.

**Note**: the DevTools is still experimental and under active development, so do be prepared for occasional unexpected behaviour, and please report issues directly to [https://github.com/nuxt/devtools](https://github.com/nuxt/devtools) 🙏

## 📚 Layers Improvements

We now support [transforming `~`/`~~`/`@`/`@@` aliases within layers](https://github.com/nuxt/nuxt/pull/19986), meaning you now no longer need to use relative paths when importing within layers.

This should mean it is much easier to use a 'normal' Nuxt project as a [layer](https://nuxt.com/docs/getting-started/layers#layers) without needing to specially write it as one.

## 🧸 Better Context Transforms

We [now transform certain keys](https://github.com/nuxt/nuxt/pull/20182) of `definePageMeta` and `defineNuxtComponent` which means you should have fewer issues with a missing Nuxt instance. This includes support accessing the Nuxt instance after an `await` within `asyncData` and `setup` functions for those still using the Options API. And you no longer need to wrap `middleware` and `validate` with `defineNuxtRouteMiddleware` when using async functions.

## ♻️ Ecosystem Updates

As usual, this release will pull in upstream improvements, including the new [Consola v3](https://github.com/unjs/consola) and [Nitropack v2.3.3](https://github.com/unjs/nitro) (a new minor is expected shortly).

## 🚨 'Breaking fixes'

We've also taken the opportunity to do some cleanup in this minor release.

1. Previously it was possible to pass the `x-nuxt-no-ssr` header (undocumented) to force SPA rendering. We've now disabled this behaviour by default but you can get it back by setting `experimental.respectNoSSRHeader` to true. Alternatively, you can set `event.context.nuxt.noSSR` on the server to force SPA rendering.
2. We've [removed the (deprecated) `#head` alias](https://github.com/nuxt/nuxt/pull/20111) and also disabled the [polyfill for `@vueuse/head` behaviour](https://github.com/nuxt/nuxt/pull/20131) by default. (It can still be enabled with `experimental.polyfillVueUseHead`.)
3. We've [removed the (deprecated) `experimental.viteNode` option](https://github.com/nuxt/nuxt/pull/20112). It can be configured instead with `vite.devBundler`.
4. We've [deprecated accessing public runtime config without the `public` key](https://github.com/nuxt/nuxt/pull/20082). This was an undocument compatibility measure with Nuxt 2 and we plan to remove it entirely in v3.5.
5. To fix a bug with our vue-router integration, we now generate a slightly different path matching syntax. If you were relying on the exact path generated, have a look at [https://github.com/nuxt/nuxt/pull/19902](https://github.com/nuxt/nuxt/pull/19902) for more information.

## ✅ Upgrading

As usual, our recommendation for upgrading is to run:

```sh
npx nuxi upgrade --force
```

This will refresh your lockfile as well, and ensures that you pull in updates from other dependencies that Nuxt relies on, particularly in the unjs ecosystem.
