React Server Components Explained: What Runs Where and What Ships

The browser downloads code for parts of the page that never change, then waits again to fetch their data. Phones on slow networks feel both delays. React Server Components are React's answer to that waste.

Picture a common setup. An online shop has a product page for a steel water bottle priced at Rs 349. The page shows a title, a description written in Markdown, a plain-text formatting style, a list of reviews and one Like button. The setup is made up, but the problem is real.

In a classic React app, every one of those components is JavaScript the browser must download. The Markdown library comes too, even though the description never changes after it loads. Then the page asks an API for the product data and renders a spinner while it waits.

Only the Like button actually needs to run in the browser. Everything else could be prepared on the server, close to the data. This guide follows that one product page from the database to the screen.

You need five words: component, bundle, bundler, hydration and serialise. Each gets a plain meaning here, and the rest of the guide builds on them.

Component. A component is a JavaScript function that returns a description of some UI, such as a heading or a button. React calls your components and builds the page from what they return.

Bundle and bundler. A bundle is the set of JavaScript files the browser downloads. A bundler is the build tool that decides what goes into it, such as webpack, Parcel or Turbopack.

Hydration. Hydration is the step where React in the browser attaches event handlers and state to HTML that already arrived from the server. Before hydration, a button is visible but does nothing when tapped.

Serialise. To serialise a value is to turn it into text so it can travel over the network, then rebuild it on the other side. A number serialises easily. A function that closes over local variables cannot be written down as text.

React Server Components are components that render ahead of time in a separate environment, before your app is bundled. React's docs call that environment the server. It can be a web server handling each request, or your build machine running once.

A Server Component can be an async function. It can await a database read in the middle of rendering, because it never runs in the browser. As it renders, React writes the output as a stream of text, usually called the RSC payload.

The browser receives that payload, not the component's code. Wherever the payload says a Client Component belongs, the browser downloads that component's JavaScript and runs it. The rest is already finished UI.

An analogy helps with the hardest idea. A newspaper is printed at the press, and you receive finished pages, not the press. The crossword is the one part you work on at home with a pencil.

The press is the server, the printed pages are the RSC payload, and the crossword is a Client Component. You never need the press in your house to read the news. You do need the pencil, which is the client JavaScript.

Where the picture breaks: a newspaper is printed once, but a server can render fresh output for every request. Also, the payload is not finished HTML. It is a description of the UI that React turns into the page.

Server Components run on the server and never in the browser. Client Components run in the browser, and they can also run on the server during SSR to produce first-load HTML. The table sums up the difference.

The hooks row is easy to check. Run React 19.3.1 in Node.js with the react-server condition, which is the flag that loads React's server build. In our run, typeof React.useState printed undefined, while the normal build printed function.

The 'use client' line marks a file and every file it imports as client code. React's docs say it creates a boundary in the module dependency tree, which is the map of which file imports which. It does not mark one component alone.

A directive is just a string at the very top of a file, above any imports. Quotes must be single or double, not backticks. Plain Node.js treats it as a meaningless string, so a bundler or loader has to act on it.

We checked this with the Node.js loader hook that ships in react-server-dom-webpack 19.3.1. With the hook on, requiring our LikeButton.js file returned an object tagged react.client.reference instead of the function. Without the hook, the same file returned the plain function.

Nesting inside a Client Component does not move code to the browser

Suppose the product page passes a server-rendered Reviews list into a client Tabs component as its children. Reviews stays a Server Component. React renders it on the server first, and Tabs only receives the finished result.

The rule from React's docs is short. If a Client Component's file imports a component, that usage becomes client code. If a Server Component renders it and hands it down as a prop, it stays on the server.

Two practical results follow. First, put 'use client' as low in the tree as you can, on the small interactive leaf. Second, a helper file imported by a client file is shipped to the browser, directive or not.

You can pass only serialisable props: plain data, a few built-in types, JSX, promises and Server Functions. React's use-client reference lists the allowed types. We ran each case through react-server-dom-webpack 19.3.1 to see what happens.

The errors did not crash the server in our run. React passed each one to the onError callback and wrote an error row where the value should be. In production mode that row carried an empty digest, a field meant for an error ID, so the payload did not include the message.

The RSC payload is the text stream a Server Component render produces. Inside React's code the format is called Flight: the server file is ReactFlightServer.js, and the package README calls it React Flight bindings. That README still labels the package experimental as of 23 October 2026. Here is a tiny render with no JSX.

const React = require('react');
const { renderToPipeableStream, registerClientReference, registerServerReference } =
  require('react-server-dom-webpack/server');

const h = React.createElement;

// A stand-in for a database row. costPrice must never reach the browser.
const db = {
  getProduct: async function (id) {
    return { id: id, name: 'Steel water bottle', price: 349, costPrice: 180 };
  }
};

// A Client Component, as a bundler would see it: only a reference.
const LikeButton = registerClientReference(
  function () { throw new Error('Client code cannot run on the server'); },
  'LikeButton.js',
  'default'
);

// A Server Function: runs on the server, the browser only gets an ID.
async function addToCart(productId) {
  return 'added ' + productId;
}
registerServerReference(addToCart, 'actions.js', 'addToCart');

// An async Server Component that reads data during render.
async function ProductPage(props) {
  const product = await db.getProduct(props.id);
  return h('main', null,
    h('h1', null, product.name),
    h('p', null, 'Price: Rs ' + product.price),
    h(LikeButton, { productId: product.id, onAdd: addToCart })
  );
}

const manifest = {
  'LikeButton.js#default': { id: './LikeButton.js', chunks: ['like-chunk', 'like-chunk.js'], name: 'default' }
};

const stream = renderToPipeableStream(h(ProductPage, { id: 'p42' }), manifest);
stream.pipe(process.stdout);

Run it with NODE_ENV=production node --conditions react-server flight.js after installing react, react-dom and react-server-dom-webpack at 19.3.1. Without the flag, the package throws an error asking for the react-server condition. Our output was three rows.

1:I["./LikeButton.js",["like-chunk","like-chunk.js"],"default"]
2:{"id":"actions.js#addToCart","bound":null}
0:["$","main",null,{"children":[["$","h1",null,{"children":"Steel water bottle"}],["$","p",null,{"children":"Price: Rs 349"}],["$","$L1",null,{"productId":"p42","onAdd":"$h2"}]]}]

Read the rows from the bottom. Row 0 is the page: tag names, props and text, already rendered. Where the Like button goes, it says $L1, a pointer to row 1.

Row 1 tells the browser which module to load for the Client Component, and which chunks hold it. Chunks are the separate JavaScript files a bundler splits code into. Row 2 stands for addToCart. The browser gets only an ID, and $h2 in row 0 points to it.

Notice what is missing. The costPrice field never appears, because ProductPage did not render it or pass it on. The db object and the async ProductPage function stayed on the server.

The payload streams in pieces

The payload is not one big JSON document. When part of the tree waits inside a Suspense boundary, React sends the ready parts first. A Suspense boundary is a wrapper that shows a fallback until its children are ready.

We wrapped a Reviews component that waits 500 ms (made up) in Suspense. In one run, the first chunk arrived at about 31 ms with the title and a Loading reviews fallback. The reviews row arrived at about 531 ms as a separate row 2.

SSR, or server-side rendering, turns components into HTML for the first page load. React Server Components produce the RSC payload instead, and their code never ships. The two solve different problems and are often used together.

With SSR alone, every component still ships to the browser and hydrates there. The server mainly gave you HTML for a faster first paint. With Server Components, the server-only parts never hydrate at all, because the browser never gets their code.

React's docs describe SSR as optional on top of RSC. We tested the combination. A second Node.js process, started without the react-server condition, read our payload and passed it to react-dom/server.

That process produced HTML with a main element, a heading, the price paragraph and a button reading Like (0) for p42. The LikeButton function ran there during SSR, using useState. The ProductPage code never ran in that process.

For a full tour of SSR, CSR and static generation as page-level choices, read the rendering patterns guide linked at the end. Beginners can stop here: you now know the model.

A Server Function is an async function that the browser can call, while its code runs on the server. You mark it with 'use server' at the top of its body, or at the top of a file to mark every export.

A common mistake is to think 'use server' marks Server Components. React's docs say plainly that there is no directive for Server Components. The 'use server' line is only for Server Functions.

Until September 2024, React called all of these Server Actions. Now a Server Action is a Server Function passed to a form's action prop or called from inside an action. Every Server Action is a Server Function, but not the other way round.

Arguments must be serialisable, and the list differs a little from props. FormData is allowed, so forms work. JSX, ordinary functions, class instances and browser events are not allowed as arguments.

Pass a Server Function to a form's action and React can submit the form before the JavaScript bundle has loaded. React's docs call this progressive enhancement. The useActionState hook adds pending state and the last result in a Client Component.

React's docs also say Server Functions are designed for mutations, meaning writes that change server state. They are not recommended for data fetching. Frameworks typically process one action at a time and do not cache the return value.

Bundle size drops by the code of every component and library used only on the server. React's docs show a Markdown example where 75K of libraries, measured after gzip compression, leaves the bundle. That is their example, and we did not measure it ourselves.

For our product page, the Markdown library moves into the Server Component that renders the description. The browser receives the rendered paragraphs. It never downloads the library, because no client file imports it.

Data fetching changes too. Without Server Components, the page renders, then calls an API from an effect, then renders again. With them, the component awaits the database during render, so no extra round trip is needed.

Low-priority data can wait without blocking the page. React's docs show a Server Component that starts a promise and passes it to a Client Component unresolved. The Client Component reads it with the use API inside Suspense.

Treat everything that crosses the boundary as public, in both directions. Data going out ends up in the payload. Arguments coming in are written by the user's device. Our tests found three easy ways to leak.

Three leaks we reproduced on React 19.3.1

• Whole objects as props. Passing a full database row sent every field, including costPrice, even though nothing displayed it. Pick fields explicitly before passing them.
• Bound arguments. We bound a Server Function to a fake internal discount code with bind. The payload carried that code in plain text, in a row the browser receives.
• Trusted arguments. A tampered call claiming a price of Rs 1 was decoded on the server exactly as sent. Look prices and permissions up on the server instead.

React's docs say to validate every Server Function argument and check that the logged-in user may perform the action. React also has taint APIs that block chosen values from reaching the client. As of 23 October 2026 they are experimental, and the stable 19.3.1 build does not export them.

Some frameworks add their own protection for values captured by inline Server Functions. That is framework behaviour, not React's, and we did not test it. Check your framework's documentation rather than assuming.

Run a release that includes every fix, which as of 23 October 2026 means 19.3.1 or the latest patch of your 19.x line. The history explains why patching matters here.

On 3 December 2025, React disclosed CVE-2025-55182. A CVE is a public ID for a security flaw. It was rated CVSS 10.0, the top of the 0 to 10 severity scale. A flaw in how React decoded payloads sent to Server Function endpoints allowed unauthenticated remote code execution, meaning anyone could run their own code on the server. It affected react-server-dom-webpack, react-server-dom-parcel and react-server-dom-turbopack.

React's post says an app could be vulnerable even with no Server Functions, if it supports Server Components. Apps that do not use a server, or no RSC-capable framework or bundler, were not affected. Fixes landed in 19.0.1, 19.1.2 and 19.2.1. These are no longer enough, as the version callout below shows.

A follow-up post on 11 December 2025, updated on 26 January 2026, added denial-of-service issues, where a crafted request hangs or crashes the server, and a source code exposure issue. Secrets hardcoded in Server Function source could leak, but runtime values read from process.env were not affected.

Search the output for something only the server should know. If a fake marker shows up in the payload or the client JavaScript, it has crossed the boundary. These steps work with any setup.

1. 1

   Plant a fake marker

   Put a fake value such as FAKE-SUPPLIER-TERMS in a server-only field, and import a library only from a Server Component.

2. 2

   Build for production

   Run your production build. Development builds add debug rows, such as component stacks, that production leaves out.

3. 3

   Search the client bundle

   Search the built JavaScript files for the marker and for a distinctive string from the library. Minifiers drop names, so zero matches is a good sign, not proof. Confirm with your bundler's analyser.

4. 4

   Search the payload

   Open the browser's network tab, load the page and search the responses for the marker. Our 19.3.1 test showed costPrice only when a whole row was passed.

5. 5

   Tamper with a call

   Replay a Server Function request with a changed argument, using fake values only. The server should reject it or ignore the changed field.

They help least when almost every part of the page is interactive, such as a drawing app or a spreadsheet. Most components there would need 'use client' anyway, so little code stays on the server.

They also need a bundler or framework that supports them, plus a server or a build step. React's docs say the underlying bundler APIs may break between minor versions, so building your own setup means pinning React. For app builders, React's docs point to full-stack frameworks that support them.

Start from the cost you are removing, then draw the boundary, then cover safety. Interviewers want to hear what runs where and what crosses the wire.

1. 1

   Name the problem

   Static parts of the page ship code and wait for data in the browser. Server Components move that work next to the data.

2. 2

   Draw the split

   Mark the server tree, the 'use client' leaves and the RSC payload between them. Say that the boundary follows imports, not nesting.

3. 3

   Show the wire

   Explain that only serialisable values cross, that Client Components arrive as module references, and that the payload streams with Suspense.

4. 4

   Place SSR correctly

   Say SSR is optional and only turns the first load into HTML. Server Components decide which code ships at all.

5. 5

   Cover writes and safety

   Use Server Functions for mutations. Validate and authorise every argument, pass only needed fields, and keep the react-server-dom package patched.