App Router and Pages Router are not just two ways to organise files in Next.js. They reflect two different mental models for where React code runs. Picking the wrong one for your application is a six-month tax. Knowing the difference is the most important Next.js decision in 2026.
The short version: for new builds in 2026, App Router is the right default — smaller client bundles, better SEO, cleaner data fetching. For existing Pages Router apps that work well, migration is optional, not urgent. The interesting question is when each architecture is the correct call and what Server Components actually change about React.
What changed: the Server Components model
The defining feature of App Router is React Server Components (RSC). In Pages Router (and in vanilla React), every component is a client component — it runs in the browser, ships JavaScript to the browser, and re-renders on state changes. Server-side rendering exists, but the components themselves are still client components running once on the server then hydrating on the client.
In App Router, components are server components by default. They run ONLY on the server, ship ZERO JavaScript to the browser, and cannot use useState, useEffect, event handlers, or browser APIs. To use any of those, you opt the component into being a client component by adding the "use client" directive at the top of the file.
This sounds like a small change. It is not. It changes where data fetching happens, how components compose, how the bundle is split, and how you reason about your application's architecture. Done well, the result is dramatically less JavaScript shipping to the browser. Done badly, the result is hydration mismatches, server-client mental model confusion, and a codebase that is harder to maintain than the Pages Router version would have been.
Three scenarios where App Router earns the complexity
Scenario 1 — Content-heavy sites where most components are static
Marketing sites, blogs, e-commerce product pages, documentation, publications. Most components on these pages do not need interactivity — they display content fetched from a CMS or database, then sit there. Server Components are perfect for this. Total client-side JavaScript drops dramatically because most of the page is rendered on the server and shipped as HTML.
For a typical content-led marketing site, App Router cuts client JavaScript from 200-300 KB (Pages Router with full client React) to 30-80 KB (App Router with selective client components for forms, modals, and search). That is a real improvement in Core Web Vitals, especially LCP and INP.
Scenario 2 — Apps with heavy server-side data needs
Applications where most data lives in databases or third-party APIs that should not be exposed to the browser. Server Components let you fetch data directly in the component, using async/await, with no useEffect, no loading states, no client-side state management. The component runs on the server, fetches the data, renders the HTML, sends it to the browser.
For applications that previously used a heavy combination of useEffect + react-query + custom hooks just to fetch and display data, App Router collapses that to a 5-line async server component. The simplification is real and the performance gain (no client-side data fetching waterfall) is significant.
Scenario 3 — Multi-region apps with edge rendering
Next.js's Edge Runtime + Vercel Edge Functions work cleanly with App Router. Server Components can run at the edge (closest data centre to the user), fetching data and rendering HTML within 50-100 ms. For global applications where every millisecond of TTFB matters, App Router + Edge is the right architecture. Pages Router supports edge too but with more friction.
Three scenarios where Pages Router is still right
Scenario 1 — Existing apps that work well
If you have a production Pages Router app that ships reliably, your team understands the patterns, and performance is acceptable, migration to App Router is a real engineering project with real risk. The upgrade is not free — expect 4 to 12 weeks of refactoring depending on app size, plus a stabilisation period where new bugs surface. Unless you have a specific reason to migrate (planning major features that benefit from RSC, or hitting performance walls that App Router would solve), staying on Pages Router is the conservative and often correct choice.
Scenario 2 — Teams new to Next.js
Pages Router's mental model is simpler: files in /pages are routes, components are React components, server-side rendering is opt-in via getServerSideProps. Most React developers can be productive in Pages Router within a few days. App Router's mental model is harder: server vs client component distinction, streaming, suspense boundaries, server actions, parallel routes. For teams without prior App Router experience, the learning curve adds 4 to 8 weeks to the first project.
If the team needs to ship in 3 months and has not used App Router before, Pages Router is the safer choice. Migrate later when the team has bandwidth.
Scenario 3 — Heavy client-side interactivity
Applications where most components are interactive — dashboards with charts and filters, editors, drag-and-drop interfaces, real-time collaboration tools, video players, complex form wizards. Every component being a client component is the right default for these apps. App Router can do this (mark everything “use client”), but you lose much of the benefit and add complexity for no gain.
For a SaaS dashboard or product application where 90% of components are interactive, vanilla React + Vite or Next.js Pages Router are both better fits than App Router.
The Server Components mental model
Three principles that, once understood, make App Router make sense:
1. Server Components cannot use state, effects, or browser APIs. No useState, no useEffect, no onClick handlers, no window or document references. They are essentially fancy template functions that fetch data and return JSX.
2. Client Components can import Server Components only as children passed via props. A client component cannot import and render a server component the way it imports another client component. The pattern is: server components in the tree wrap client components, passing data down via props.
3. The “use client” directive is a boundary, not a rendering mode. When you mark a file “use client”, everything that file imports (and that imports are imported) becomes part of the client bundle. The directive defines the boundary where the server-rendered HTML becomes hydrated React; everything inside that boundary ships to the browser.
Get those three right and App Router becomes coherent. Get them wrong and you end up with a frankenstein architecture where you have client components doing data fetching, server components trying to handle clicks, and a confusing mess where the boundary leaks.
The honest decision framework
Two questions usually resolve the choice:
Question 1: Is this a new build or an existing app? For new builds in 2026, App Router is the right default. For existing Pages Router apps that work, leave them on Pages Router unless you have a specific reason to migrate.
Question 2: Does your team know App Router patterns? If yes, App Router is the modern default. If no, either factor 4 to 8 weeks of learning into the schedule, or use Pages Router until the team has time to learn App Router properly.
What we ship
Roughly 70% of our new Next.js builds in 2026 are App Router. Roughly 25% are Pages Router (either client preference, team preference, or specific architecture reasons). The remaining 5% are migrations from Pages Router to App Router for clients who have outgrown Pages Router's patterns.
When clients come to us with the decision unmade, we recommend App Router by default for new builds, but we will pick Pages Router if the team or the application argues for it. Architecture follows business need, not framework trend.
Common questions
Should I migrate my existing Pages Router app to App Router?
Usually no, not yet, unless you have a specific reason. The migration is 4 to 12 weeks of work depending on app size, plus a stabilisation period where new bugs surface. Reasons that DO justify migrating: planning major new features that benefit from Server Components or streaming, hitting performance walls that App Router would solve, or rebuilding significant parts of the codebase anyway. If your Pages Router app works well and the team is productive, staying on Pages Router is the conservative call.
What’s the actual performance difference between App Router and Pages Router?
For content-heavy pages where most components are static, App Router with Server Components ships dramatically less JavaScript to the browser — typical reduction from 250 KB to 50 to 80 KB. That improves LCP by 200 to 600 ms and INP by 50 to 150 ms. For interactive apps where most components are client components, the performance difference is minimal because both routers ship roughly the same JavaScript bundle. The bigger the static portion of the page, the bigger the App Router advantage.
Can I use App Router and Pages Router in the same Next.js app?
Yes. Next.js supports both routers in the same application during the transition period. Routes under /app use App Router; routes under /pages use Pages Router. This is the recommended path for incremental migration — move pages over one at a time as you refactor them. There are some constraints (shared layouts, middleware) but for most applications the hybrid approach works for the months or years it takes to fully migrate.
What about Server Actions — are they ready for production?
Yes, as of 2024. Server Actions let you mutate data on the server from a client component without writing API routes. The pattern is mature in production at scale (Vercel uses them internally for their own products). The mental model is closer to traditional form submissions than to fetch-based mutations, which feels new to React developers used to onSubmit handlers but cleaner once you internalise it. We use Server Actions for most form submissions and mutations in App Router builds.
Is App Router stable enough for production now?
Yes, comfortably. App Router has been stable since Next.js 13 (October 2022) and has had years of production use across Vercel, every Next.js framework adopter, and our own client builds. The Server Components and Server Actions APIs are stable and well-documented. The remaining rough edges are mostly around third-party library compatibility — some libraries assume client-side rendering and need adjustment for the server-component context. Those issues are tractable and well-covered in the ecosystem.
Deciding between App Router and Pages Router?
Tell us about the application, the team, and the timeline. We will tell you which router fits your case better — and give you a realistic migration estimate if migration is worth it.