# Server Components vs Client Components
One of the most confusing parts of modern Next.js is deciding whether a component should run on the server or the client. The distinction isn't stylistic — it changes what the component can and can't do.
## Server Components
By default, every component in the App Router is a Server Component. It renders on the server, can directly query a database or call an API without exposing keys to the browser, and sends zero JavaScript for that component to the client.
## Client Components
Add `"use client"` at the top of a file to opt into a Client Component. These support interactivity — `useState`, `useEffect`, event handlers, and browser-only APIs like `localStorage`.
## The Boundary Problem
Once you mark a file as a Client Component, everything it imports also runs on the client. A common mistake is wrapping an entire page in `"use client"` just because one small piece needs interactivity, which unnecessarily ships extra JavaScript.
## A Practical Pattern
Keep data-fetching and layout logic in Server Components, and push only the truly interactive pieces — a dropdown, a form, a like button — into small Client Components. This keeps bundles lean.
```tsx
// page.tsx (Server Component)
export default async function Page() {
const data = await getData();
return
Back to Blogs
Server Components vs Client Components
What actually separates a Server Component from a Client Component in Next.js, and how to decide which one your component should be.
20 Aug 2026
6 min read
