Next.js App Router vs Pages Router: Which Should You Use in 2026?

The App Router should be your default for every new Next.js project in 2026: it is the only router where layouts nest, loading and error states are file-level primitives, streaming works out of the box, and React Server Components eliminate client-side JavaScript by default. The Pages Router remains fully supported and is still the right choice for existing applications that are stable, feature-complete, and not blocked on streaming or server components.

A Short History of the Two Routers

The Pages Router is the original Next.js routing system. It shipped with the framework in 2016 and powered every version through Next.js 12: routes map to files in a pages/ directory, data enters a page through getServerSideProps, getStaticProps, or getInitialProps, and everything rendered to HTML on the server is hydrated as a React client component. That mental model — one component tree, rendered twice — is simple, and a decade of tutorials, libraries, and production apps are built on it.

The App Router became stable in Next.js 13.4 in May 2023 and was hardened through the Next.js 14 and 15 releases: routes live in an app/ directory, pages are React Server Components by default, and data fetching is an ordinary async function call rather than a special export. By 2026 the App Router is what the Next.js team ships features for first: the caching model, Server Actions, Partial Prerendering, and typed routes all assume app/.

Both routers ship in the same framework today. You can even run them side by side in one project during a migration. The question is no longer "is it stable?" — it is "which constraints does my project actually have?"

Data Fetching

This is the biggest conceptual shift. In the Pages Router, data fetching is a framework-level convention: special exported functions run before the component, and their return value is passed in as props. In the App Router, data fetching is just JavaScript — an async Server Component can await a fetch, a database query, or an ORM call directly, anywhere in the tree.

Two practical consequences follow. First, you can colocate data requirements: a sidebar component fetches its own data instead of hoisting everything to the page. Second, the fetch API inside app/ is memoized and cache-aware, with next: { revalidate: 60 } controlling staleness per request.

// pages/products/[slug].tsx — Pages Router
export async function getServerSideProps(context) {
  const { slug } = context.params;
  const product = await db.products.findBySlug(slug);
  return { props: { product } };
}

export default function ProductPage({ product }) {
  const [reviews, setReviews] = useState([]);

  useEffect(() => {
    fetch(`/api/reviews/${product.id}`).then((r) => r.json()).then(setReviews);
  }, [product.id]);

  return <ProductDetail product={product} reviews={reviews} />;
}

The same feature in the App Router drops the special export and the useEffect fetch entirely, because the child component that needs reviews can fetch them on the server:

// app/products/[slug]/page.tsx — App Router
export default async function ProductPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const product = await db.products.findBySlug(slug);

  return (
    <>
      <ProductDetail product={product} />
      <Suspense fallback={<ReviewsSkeleton />}>
        <Reviews productId={product.id} />
      </Suspense>
    </>
  );
}

Verdict: the App Router wins on flexibility and colocated fetching; the Pages Router wins on predictability, because getServerSideProps always runs on the server before render and never accidentally ships a secret to the client. In the App Router you must be deliberate about which components are client components, since a "use client" boundary turns everything below it back into the Pages Router mental model.

Layouts and Nesting

The Pages Router has no first-class layout primitive. The standard workaround is a Higher-Order Component — wrap every page in withLayout(Page) — or accept a remount of the whole shell on navigation, which resets scroll position and re-fetches whatever the shell needed. _app.tsx gives you one global layout and nothing in between.

The App Router treats a layout as a file. A layout.tsx wraps every route beneath it, persists across client-side navigation, and nests to arbitrary depth. Route groups in parentheses let you give different sections of the site different shells without affecting the URL.

// app/(marketing)/layout.tsx — shared layout for a route group
export default function MarketingLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="marketing-shell">
      <SiteHeader />
      <main>{children}</main>
      <SiteFooter />
    </div>
  );
}

// app/(marketing)/pricing/page.tsx renders inside that layout
// app/(app)/dashboard/page.tsx does not — different group, different shell

Because layouts do not remount on navigation, state inside a layout survives route changes — a persistent audio player, an open sidebar, a draft editor. That single property removes most of the state-restoration code teams end up writing in the Pages Router.

Loading and Error States

In the Pages Router, loading and error UX is hand-rolled: a spinner in useEffect, a getServerSideProps try/catch that redirects, an Error Boundary component you wire up manually. Nothing about the file system expresses "this route is loading" or "this route failed."

The App Router makes both file-level conventions: loading.tsx renders instantly while the segment's data resolves, and error.tsx is a React Error Boundary scoped to that segment — it can be as deep as you like, so a failing widget does not take down the page. A global not-found.tsx handles 404s and global-error.tsx catches render failures at the root. Because these files wrap segments rather than whole pages, error recovery preserves layout and navigation state.

Streaming and Suspense

Streaming is where the two routers diverge most sharply. The Pages Router sends one HTML document after the slowest getServerSideProps promise settles — there is no way to flush shell HTML early and fill in slow regions afterward, short of hand-building endpoints outside Next.js.

The App Router streams by default. React renders on the server, the shell is flushed as soon as it is ready, and anything wrapped in <Suspense> streams in when its data arrives. The loading.tsx file is syntactic sugar for a Suspense boundary around the whole segment. Combined with await inside the component, this gives you granular, per-component skeletons instead of a full-page spinner.

For Largest Contentful Paint, the difference is measurable: a hero rendered from cached data ships in the first chunk while a slow recommendations call streams in behind it. On the Pages Router, that same slow call delays the entire response. Partial Prerendering extends this further, shipping a static shell immediately and streaming the dynamic holes — but it is an App Router feature only.

Colocation

The Pages Router forces a strict separation: components that run on the server (data functions) live at the top of the file, components that run on the browser live anywhere, and anything imported by a page ends up in the client bundle unless you carefully code-split it. A page directory becomes a flat list of routes with components exiled to components/ two folders away.

The App Router colocates. A route folder can contain the page, its layout, its loading and error files, unit-test files, and helper modules that never reach the browser — because Server Components have no client runtime, anything imported beneath a server boundary is excluded from the bundle automatically. Colocation also scales horizontally: feature folders own their routes, tests, and data access together.

API Routes vs Route Handlers

Pages Router API routes live in pages/api/ and export one function per HTTP verb — GET, POST — receiving a Next.js-specific req/ res pair. Route Handlers in app/api/ use the Web-standard Request and Response objects, can export dynamic segment config, and run on Node.js or the Edge runtime without changing your handler signature.

// app/api/reviews/route.ts — Route Handler
import { NextResponse } from "next/server";

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const productId = searchParams.get("productId");

  const reviews = await db.reviews.findMany({ productId });
  return NextResponse.json(reviews);
}

export async function POST(request: Request) {
  const body = await request.json();
  const created = await db.reviews.create(body);
  return NextResponse.json(created, { status: 201 });
}

The practical advantage: handlers written against Web standards are portable. Code that reads request.json() and returns NextResponse.json() can move to a worker runtime, a different framework, or a test harness with minimal changes. Route Handlers also support streaming responses and Webhooks in a file that coexists with the pages that consume them.

TypeScript and Component Conventions

Both routers support TypeScript, but the App Router bakes stricter conventions into the framework. Page, layout, and route params are typed through generated .d.ts files, so renaming a dynamic segment changes your types and surfaces every broken call site at compile time. With typed routes enabled, internal <Link href="/products/[slug]"> calls become checked as well.

Component conventions differ too. The App Router makes "use client" an explicit opt-in boundary rather than an implicit default, and hooks like useRouter, usePathname, and useSearchParams moved from next/router to next/navigation. Server-only libraries — database clients, SDKs with secrets, heavy parsers — become safe to import directly into a component, guarded by import "server-only" when you want a hard build error if they leak clientward.

Migration Cost

There is no automated one-shot migrator that converts an arbitrary Pages Router app into an App Router app, because the change is architectural rather than syntactic. The realistic path is incremental: keep pages/ and add app/ — Next.js resolves app/ first for any route that exists in both, so you can move one route at a time and keep the rest working.

Typical migration work, in rough order of effort:

1. Create a root layout — move the contents of _app.tsx and _document.tsx into app/layout.tsx, including fonts, metadata, and the html/body tags.
2. Split data functions into fetches — rewrite getStaticProps as fetch with revalidate and getServerSideProps as dynamic fetch or a database call.
3. Mark client boundaries — add "use client" to components using hooks or browser APIs, then try removing it from each parent.
4. Move API routes — pages/api/* can stay put indefinitely while new handlers land in app/api/*.
5. Replace head management — next/head and getServerSideProps metadata become the exported metadata object or generateMetadata.

For a marketing site of 20 pages this is a day of work. For a large application with hundreds of routes, deep third-party integrations, and Pages-Router-only libraries, it is a multi-quarter project — which is exactly why the incremental coexistence model exists.

Ecosystem and Library Maturity

In 2026 the library ecosystem has largely converged. The major state, form, table, auth, and data-fetching libraries ship App Router guides, and most component libraries work unchanged as long as you add a client boundary. Server Actions and "use server" have no Pages Router equivalent at all.

Gaps that still matter are narrower than they were: libraries that assume browser globals at module scope, packages that were never SSR-safe, and analytics or feature-flag SDKs whose documented patterns still center on _app.tsx. If your stack leans on a specific unmaintained package, check its App Router support before committing to a rewrite — a library pinned to the Pages Router is a legitimate reason to delay.

When the Pages Router Is Still the Right Call

The Pages Router is not deprecated, and choosing it is not a mistake. Three situations genuinely favor it:

• Stable legacy applications — a mature product with no streaming requirement, a green performance budget, and a backlog of feature work far more valuable than a router rewrite. Next.js continues to ship security and bug fixes to the Pages Router.
• Simpler mental model — one component tree, props in from the top, everything client-side. For teams new to React, or for prototypes where server/client boundaries add cognitive overhead with no payoff, the Pages Router is easier to reason about.
• Pages-Router-only dependencies — middleware patterns, custom servers, or libraries that have never been updated for app/. Migration cost here is real and should be weighed against the benefit, not assumed away.

Decision Table

Run your project through this table before deciding. The "App Router" column is the default for a reason, but any single row can flip the answer.

Verdict for New Projects

Use the App Router for new projects. File-level layouts, loading and error states, streaming, colocated data fetching, Server Components, Server Actions, Route Handlers, and Partial Prerendering are not incremental conveniences — together they change the performance profile and the code structure of an application. Starting a 2026 project on the Pages Router means opting out of the entire direction of the framework on day one.

The corollary is equally important: do not migrate a healthy Pages Router application just because the App Router exists. Rewrite when you have a concrete reason — streaming, a bundle size problem, a redesign that touches every route anyway — and move incrementally, route by route, with both routers running side by side until the last pages/ file is gone.