# Astro vs Next.js
URL: https://wwadd.dev/compare/astro-vs-nextjs
Last verified: 2026-10-12

For a publishing site, ask how much of each page is content and how much is application UI. Both can produce indexable HTML and integrate a CMS; neither supplies your editorial workflow automatically.

## Verdict
Start with Astro for content pages with small interactive islands. Choose Next.js when publishing is part of a React application with substantial shared UI and authenticated features. Astro can render on demand and Next.js can export static pages, so neither label decides the whole architecture. Test editor previews, publish/update behavior, and one representative page's JavaScript before committing.

## Pick Astro when
- Most pages are articles, docs, or marketing content, with a few independent interactive elements
- You want content collections and a static publishing workflow, adding request-time rendering only where needed

**Skip Astro if:** most routes require shared React application state and your team cannot maintain the boundary between islands and the surrounding pages.

## Pick Next.js when
- The publishing site shares substantial React UI and authenticated application features with your product
- You need integrated application routes and can maintain content loading, caching, and preview access

**Skip Next.js if:** the site is mostly articles and a few widgets, and your team has no need for React application features or its server/cache model.

## Related tools
- [Astro](https://wwadd.dev/tools/astro)
- [Next.js](https://wwadd.dev/tools/nextjs)

## Related playbooks
- [Next.js + Postgres + Prisma + Vercel](https://wwadd.dev/stacks/nextjs-postgres-prisma-vercel)
- [Astro + Markdown + CDN](https://wwadd.dev/stacks/astro-markdown-cdn)
- [B2B SaaS (organizations / multi-tenant): Next.js + Postgres + Better Auth](https://wwadd.dev/stacks/b2b-saas-nextjs-postgres-better-auth)

## What actually differs
- Starting point: Astro — Content pages rendered to static HTML by default, with interactive components opted in as islands; Next.js — A React application framework; Server Components keep server code out of the client bundle while Client Components provide interaction
- Publishing content: Astro — Content collections validate schemas and load local or remote content, including Markdown and MDX; Next.js — MDX integration and data fetching support local or remote content; choose your own content schema and publishing pipeline
- Interactive features: Astro — Hydrate selected React, Svelte, Vue, or other supported components; plan how islands share state; Next.js — Use React components across layouts and app routes; keep client boundaries narrow to control shipped JavaScript
- Personalized pages: Astro — An adapter enables request-time rendering for selected routes or the site; Astro is not limited to static output; Next.js — Request-time rendering supports account pages and personalized data; authorize requests and review cache boundaries
- Deployment and editorial operations: Astro — Static output works on static hosts; dynamic features require a compatible adapter and runtime; Next.js — Node, Docker, platform integrations, or static export; export cannot provide features that require a server

## Sources
- [Astro design and content focus](https://docs.astro.build/en/concepts/why-astro/)
- [Astro islands](https://docs.astro.build/en/concepts/islands/)
- [Astro content collections](https://docs.astro.build/en/guides/content-collections/)
- [Astro on-demand rendering](https://docs.astro.build/en/guides/on-demand-rendering/)
- [Next.js MDX](https://nextjs.org/docs/app/guides/mdx)
- [Next.js server and client components](https://nextjs.org/docs/app/getting-started/server-and-client-components)
- [Next.js caching and revalidation](https://nextjs.org/docs/app/getting-started/caching)
- [Next.js static export limits](https://nextjs.org/docs/app/guides/static-exports)