Next.js ships two routers. The App Router is the modern default, built around React Server Components and the app directory. The Pages Router is the original model, still supported for existing projects, but no longer the recommended starting point.
What separates the two routers
The two routers are different ways of turning files into pages, and they use different files and different mental models. The newer router arrived in Next.js 13 and became the default, while the original one dates back to the earliest framework versions. Both ship in the same framework, and an app can run the two directories side by side during a migration.
| Concern | App Router | Pages Router |
|---|---|---|
| Folder | app | pages |
| Components | Server components by default | Client components |
| Data fetching | Async server components | getServerSideProps and getStaticProps |
| API endpoints | Route handlers in route.ts | API routes in pages/api |
| Status | Recommended for new apps | Maintained for existing apps |
The App Router treats every page as a server component by default and runs data fetching inside the component. The Pages Router treats pages as client components and fetches data through separate exported functions. The mental model is the biggest change: a single component that owns its data replaces a page plus a data function.
The same page in each router
In the App Router, a blog page is an async server component:
// app/blog/page.tsx
export default async function BlogPage() {
const res = await fetch('https://api.vercel.app/blog');
const posts = await res.json();
return <ul>{posts.map((p) => <li key={p.id}>{p.title}</li>)}</ul>;
}The fetch runs on the server during rendering, and the browser receives the finished list. There is no separate function to export and no client fetch hook to write. The async component is the data layer.
In the Pages Router, the equivalent page splits into a component and an exported function:
// pages/blog.tsx
export default function Blog({ posts }) {
return <ul>{posts.map((p) => <li key={p.id}>{p.title}</li>)}</ul>;
}
export async function getServerSideProps() {
const res = await fetch('https://api.vercel.app/blog');
const posts = await res.json();
return { props: { posts } };
}Both render the same list. The App Router keeps data fetching inside the component, while the Pages Router hoists it into getServerSideProps. The result in the browser is identical, which is why the choice is about architecture rather than output.
Which one to choose in 2026
Use the App Router for every new project. It is where new React features land, including Server Components, and it is the router the documentation recommends.
The Pages Router still matters when you maintain an existing app. Migration is incremental: you can keep the pages directory, add an app directory, and move routes one section at a time. You do not have to rewrite an old project all at once.
To understand the App Router's folder conventions, read How File-Based Routing Works in the Next.js App Router. If you are moving API endpoints off the Pages Router, see API Routes vs Route Handlers.
Rune AI
Key Insights
- Next.js has two routers: the App Router and the Pages Router.
- The App Router is built around React Server Components and the app directory.
- The Pages Router uses the pages directory and separate data fetching functions.
- Use the App Router for new projects and gradual migrations.
- The Pages Router remains supported for existing apps.
Frequently Asked Questions
Is the Pages Router deprecated?
Can both routers run in one app?
Which router do new React features target?
Conclusion
The App Router is the modern default and the right choice for new projects, while the Pages Router is maintained for existing apps. Pick the App Router unless you are working in an older codebase.
More in this topic
`generateMetadata` Explained with Real Examples
What generateMetadata does, when it runs, and how to use it for real routes: awaited params, deduplicated data fetching, extending parent metadata, and returning a 404 from metadata.
Canonical URLs in Next.js: `metadataBase`, `alternates.canonical`, and Dynamic Pages
How canonical URLs work in the Next.js App Router: setting metadataBase once, writing alternates.canonical per route, handling dynamic segments, and what happens when the base URL is missing.
Open Graph and Twitter Card Metadata in Next.js
How to write Open Graph and Twitter card metadata in the Next.js App Router: the openGraph and twitter fields, automatic card defaults, article tags, and image merge rules.