Next.js Interview Questions

A curated set of Next.js interview questions, ordered roughly from rendering fundamentals to implementation detail — the kind you'll actually be asked in real screens and on-sites.

Rendering model#

Q: What's the difference between a Server Component and a Client Component? A Server Component renders on the server and ships no JavaScript for itself to the browser — it can be an async function that fetches data directly, but it can't use state, effects, or event handlers. A Client Component, marked with 'use client', is hydrated and runs in the browser, giving it access to useState, useEffect, and DOM event handlers, at the cost of shipping its JavaScript to the client. In the App Router, every component is a Server Component unless it (or an ancestor in its subtree) explicitly opts into 'use client'.

Q: What's the difference between SSR, SSG, and ISR in Next.js? SSR (server-side rendering, Next's "dynamic" mode) generates the HTML fresh on every request, needed for per-user or highly time-sensitive data. SSG (static generation, Next's default) generates the HTML once at build time and reuses it for every request, ideal for content that rarely changes. ISR (Incremental Static Regeneration) is a middle ground: pages are statically generated but automatically regenerated in the background after a configured interval, so content stays reasonably fresh without paying the cost of rendering on every single request.

Q: Why does Next.js use file-based routing instead of a centralized routing configuration? It removes an entire category of boilerplate and a whole class of bugs — a route's existence, nesting, and dynamic segments are all readable directly from the folder structure, with no separate router config file to keep in sync as routes are added or moved. It also lets Next attach special behavior to specific filenames (layout.tsx, loading.tsx, error.tsx) automatically, purely by convention, without any manual wiring.

Q: When would you use a Server Action instead of building a Route Handler? A Server Action is the better fit when a mutation is triggered from your own app's UI — typically a form submission — since it can be passed directly as a function reference without writing a separate endpoint or a client-side fetch call, and it still works with JavaScript disabled. A Route Handler is the right choice when you need an actual HTTP endpoint: consumed by an external client, a mobile app, a webhook, or anything that isn't your own app's form directly invoking a server function.

Q: What is hydration, and why can a "hydration mismatch" error occur? Hydration is the process where React attaches event listeners and internal state to server-rendered HTML already sitting in the DOM, rather than re-rendering it from scratch — turning static markup into an interactive app. A mismatch happens when the HTML React generates on the client during hydration doesn't match what the server actually sent, commonly caused by rendering something environment-dependent (the current date, Math.random(), checking window unguarded) differently on the server than in the browser.

Q: What problem do nested layouts solve in the App Router? Without layouts, every page would need to repeat shared UI (navigation, sidebars) and, more importantly, that shared UI would re-render on every navigation between pages. A layout.tsx wraps every page beneath it in the route tree and persists across navigations between its child routes — React only re-renders the page content that actually changed, not the layout around it, which also means any client-side state in the layout survives navigation.

Auth, performance, and deployment#

Q: Why should middleware only check for a session cookie's presence rather than doing a full database lookup on every request? Next.js middleware runs on a restricted Edge runtime built for fast, lightweight checks on every matched request, not a full Node.js environment suited to heavier work. Verifying that a signed session token exists (and optionally that its signature is valid) is cheap enough to do on every request; looking the session up in a database is comparatively expensive and is better done once, inside the specific page or Route Handler that actually needs the full user record, rather than on every single request the matcher intercepts.

Q: Why is a session token stored in an httpOnly cookie instead of localStorage? An httpOnly cookie is invisible to JavaScript running on the page — document.cookie simply can't read it — so a script injected through an XSS vulnerability elsewhere on the site can't steal it. localStorage has no such protection: any JavaScript that executes on the page, including injected malicious code, can read and exfiltrate whatever is stored there. This is why session/auth tokens belong in cookies (ideally httpOnly, secure, and with an appropriate sameSite value) rather than localStorage, despite localStorage being simpler to read from client-side code.

Q: What does next/image actually do differently from a plain <img> tag? It resizes and re-encodes the source image to match the size it's actually rendered at, serves a modern format like WebP when the browser supports it, and — using the required width/height props — reserves the correct space in the layout before the image data arrives, preventing the surrounding content from visibly shifting once it loads. A plain <img> does none of this: it ships whatever file exists on disk and provides no layout-shift protection on its own.

Q: When would you reach for next/dynamic instead of relying on Next's default per-route code splitting? Per-route splitting already keeps one page's JavaScript from loading another page's code, but a single page can still contain one specific component that's unusually heavy (a charting library, a rich text editor) and isn't needed by every visitor or on first render. next/dynamic splits that one component into its own chunk, loaded only when it's actually rendered — worth doing specifically for a large, conditionally-shown piece of a page, not as a default wrapped around every component.

Q: What's the practical trade-off between deploying to Vercel versus self-hosting with next start or Docker? Vercel is built by the Next.js team and matches the framework's rendering model (ISR, image optimization, middleware, Server Actions) with essentially zero configuration, at the cost of being tied to their platform. Self-hosting keeps you in full control of the infrastructure — useful for data residency requirements, cost control at scale, or fitting into an existing container platform — but means you're responsible for a persistent Node process (via a process manager), a properly configured image-optimization pipeline, and your own scaling strategy, none of which Vercel requires you to think about.