Next.js Versions: What Changed from 13 to 16, and Which Versions Are Supported?

If you are choosing a Next.js version, check the release line your app runs, not just the newest package on npm. Versions 13–16 span important changes to App Router development, request APIs, caching, and the bundler. A version such as 15.5.24 has a major number (15), a minor number (5), and a patch number (24): knowing that an app is on 15 is useful, but its patch version matters when checking security guidance.

In the August 2026 security release, Next.js identified 16.3.3 as Active LTS and 15.5.24 as Maintenance LTS. That is a dated security-patch snapshot, not a promise that either patch is still the latest published package—or that the newest npm package is the only supported line. Check current official release guidance before deciding what to deploy.

The milestones, without mixing up preview and stable

Version	What to pay attention to
13	The starting point for this comparison: first establish whether the application uses the App Router, the Pages Router, or both. The changes below do not apply identically to every route.
14	Server Actions became stable. Turbopack development work was still moving toward stable, while Partial Prerendering was presented as a preview.
15	React 19 became the minimum; request-time APIs became asynchronous; fetch requests and GET Route Handlers changed to uncached-by-default behavior.
16	Turbopack became the default bundler. Cache Components introduced an opt-in caching model, and proxy.ts replaced middleware.ts for the Node.js request-interception boundary.

This is a feature timeline, not a release-date or end-of-life table. In particular, the August 2026 security announcement names supported 15 and 16 patches; it does not establish a support status for 13 or 14.

Next.js 14: stable actions, preview rendering

The Next.js 14 announcement calls Server Actions stable. In the App Router, they let a server function handle a mutation through a form or a function call, with integration points for revalidating cached data and redirecting afterward. That is a meaningful distinction from a feature shown as a preview: you can plan around the stable feature without assuming the preview has the same settled interface.

Partial Prerendering was explicitly Preview in that announcement. Its proposed model combined a static shell, based on Suspense boundaries, with dynamic content streamed into the same response. Turbopack also had thousands of passing development integration tests, but the announcement said it would move to stable after further test coverage. Neither label means “all of Next.js 14 was preview”; it means those particular features were at different stages.

Next.js 15: check request access and caching assumptions

The version 15 upgrade guide sets the minimum versions of both react and react-dom to 19. For an existing app, review React dependencies alongside the Next.js upgrade rather than treating the framework package as the only moving part.

In App Router files, request-dependent APIs that were previously synchronous became asynchronous. The affected APIs include cookies, headers, and draftMode; params in pages, layouts, Route Handlers, and other documented entry points; and searchParams in pages. Version 15 temporarily permits synchronous access to ease migration, but the release announcement says that access produces warnings. An upgrade is a good time to update those call sites, not a reason to silence them.

Caching deserves a separate audit. In Next.js 15, fetch requests are no longer cached by default; an individual request can opt in with cache: 'force-cache'. This short fragment illustrates that App Router opt-in, not a complete data-fetching or migration recipe:

// Next.js 15 App Router: explicitly cache this fetch request.
const response = await fetch('https://example.com/api/products', {
  cache: 'force-cache',
})

The Next.js 15 announcement also changes GET Route Handlers and the Client Router Cache from cached by default to uncached by default. These are distinct caching decisions: opting one fetch request into caching does not, by itself, describe the behavior of a Route Handler or client navigation. If an application relied on implicit caching, inspect each affected path and choose explicit caching where reuse is intended. Do not carry an App Router rule over to a Pages Router route without checking that route’s own behavior.

Next.js 16: a default bundler and more explicit boundaries

The Next.js 16 announcement describes Turbopack as the stable default bundler. That is a different milestone from its development-stage status in 14 and beta production builds in 15.5.

For the App Router, Cache Components center on 'use cache', which can cache pages, components, or functions. In that model caching is opt-in, and dynamic code in pages, layouts, or API routes runs at request time by default. This is a reason to revisit caching deliberately during a 16 upgrade, rather than assume that a result previously reused will keep being reused. The release also identifies async params and changes to caching APIs among migration concerns; for example, revalidateTag() now requires a cache-life profile as its second argument.

Finally, proxy.ts replaces middleware.ts for the Node.js runtime boundary. The documented change is to rename the file and its exported function to proxy; middleware.ts remains available for Edge-runtime cases but is deprecated. Check which runtime your existing interception code uses before making that rename.

Check your app, then choose a line

Run these commands from your project directory. The first inspects the installed dependency in that project; the second asks npm for the currently published package version:

npm ls next
npm view next version

Read the installed major and patch, then compare them with current official release and security guidance. npm view answers a different question: it does not tell you which release lines still receive maintenance patches. The August 2026 snapshot points to 16.3.3 (Active LTS) and 15.5.24 (Maintenance LTS), but those exact patch numbers should not be treated as a live latest-version lookup.

Prefer a currently supported line that you can keep patched. If you are moving an older app, estimate the work from its actual usage: React 19 dependencies, asynchronous App Router request APIs, caching expectations, and any middleware.ts runtime boundary. Those checks are more useful than choosing a major number in isolation.