React Server Components vs 'use client': What Actually Ships to the Browser

Add a log to a Client Component:

"use client";

export function LikeButton() {
  console.log("rendering LikeButton"); // shows up in your terminal too
  return <button>Like</button>;
}

Load the page, and the message appears in the terminal where Next.js runs, not just in the browser console.

So "use client" doesn't mean "runs only in the browser". It means something else, and once you see what, it's clear where to put it.

The mental model: the result vs the result plus the code#

Both kinds of component render on the server first, so the browser gets real HTML. The difference is what gets sent along with it:

A Server Component sends only its result. A Client Component sends its result plus the code to run it again in the browser.

The result is enough to look at. The code is what lets a component react: to clicks, typing, state and effects.

Sheet music is enough to read a song. To play it, you need the mechanism too, and that's what a Client Component ships. Photo: Jennifer Schug, CC BY-SA 4.0, via Wikimedia Commons

How it works#

In the Next.js App Router, every component is a Server Component by default.

A Server Component runs only on the server, at build time or per request. It can be async, read a database or a file, and use secret keys. Its result is sent to the browser. Its code is never sent. A heavy library used only inside a Server Component adds zero bytes to your bundle.

A Client Component also renders on the server for the first HTML. Then its JavaScript is downloaded and React hydrates it: attaches event handlers and starts its state, so the HTML becomes interactive.

"use client" marks a boundary. The file with the directive, and everything it imports, goes into the browser bundle. You only write it at the entry point. The components it imports are client code automatically.

Data crossing the boundary#

Props passed from a Server Component to a Client Component have to travel over the network, so they must be serializable: strings, numbers, plain objects, arrays, dates, and a few more. A regular function can't be sent:

Functions cannot be passed directly to Client Components unless you
explicitly expose it by marking it with "use server".

Server Components can sit inside Client Components#

A Client Component can't import a Server Component, but it can receive one as children:

// page.tsx (Server Component)
<Modal>
  <Cart /> {/* still a Server Component: its code stays on the server */}
</Modal>

<Cart /> is rendered on the server, and Modal only gets its result. That's how a client-side wrapper (a modal, a tab panel, a theme provider) can hold server-rendered content.

In practice#

Push "use client" down to the leaves. The usual mistake is putting it at the top of a whole page because one button needs onClick:

// before: page.tsx
"use client"; // the whole page and all its imports now ship to the browser

// after: page.tsx stays a Server Component
import { LikeButton } from "./LikeButton"; // only this file has "use client"

export default async function Page() {
  const post = await getPost();
  return (
    <article>
      <h1>{post.title}</h1>
      <PostBody post={post} />
      <LikeButton postId={post.id} />
    </article>
  );
}

Now only the button's code ships. The page, the data fetching and everything PostBody imports stay on the server.

This blog works that way. Each post's MDX is compiled, and every code block is syntax-highlighted, inside a Server Component. I checked the production build: the browser chunks contain highlight.js's CSS theme, but none of its JavaScript. Readers get colored code without downloading a highlighter.

Two habits that prevent mistakes:

• Put import "server-only" at the top of files with secrets or database code. If a Client Component ever imports them, the build fails instead of leaking.
• Pass plain data (postId) to Client Components, not whole objects with methods.

Honest stakes: a Client Component in the wrong place still works. It costs bundle size and hydration time, which you feel on slow phones and big pages. Moving one "use client" from a page to a button is often the cheapest performance fix in an App Router project.

Say it in an interview#

"In the App Router, components are Server Components by default: they run only on the server, can fetch data directly, and their code never reaches the browser. "use client" marks a boundary: that file and everything it imports are bundled for the browser. Client Components still render on the server for the first HTML, then hydrate to become interactive. So I keep pages and data fetching on the server and put "use client" only on the small interactive pieces, passing them serializable props."

Cheat sheet#

TL;DR#

• Server Components send the result. Client Components send the result plus the code.
• "use client" doesn't mean browser-only: Client Components render on the server too.
• Everything a "use client" file imports ships to the browser.
• Put the directive on the smallest interactive piece and pass it plain data.

// carousel.tsx
"use client";
export { Carousel } from "some-carousel-package";