Server Component Payloads & Serialization
The invisible data format that powers Server Components, and why functions can't cross the network.
What is the RSC Payload?
When a Server Component renders, it doesn't send HTML to the browser right away. First, it generates a special, compact data format known as the React Server Component (RSC) Payload.
This payload contains the structural 'blueprint' of the rendered Server Components, along with any props that need to be passed down to Client Components.
The network boundary
In a traditional React app, all components live in the browser's memory, so they can freely pass anything to each other. In Next.js, Server Components live on the server, while Client Components run in the browser.
Between them lies a physical network boundary. The RSC Payload is the transport mechanism used to safely bridge this gap, sending only what the browser strictly needs to construct the UI.
Serialization
When a Server Component renders a Client Component and passes it a prop, that prop must travel over the internet inside the RSC Payload.
To do this, Next.js must 'serialize' the data—convert it from a living JavaScript value in memory into a string of text that can be transmitted. When it reaches the browser, it is 'deserialized' back into a JavaScript value.
The Network Boundary
Try passing different types of props from the Server to the Client to see which ones survive serialization.
Check yourself
Pick an answer to lock it in, then read why. Getting one wrong is part of how it sticks.
Remember this
- The RSC Payload is the data bridge between Server Components and Client Components.
- Data passed from Server to Client must cross a physical network boundary.
- Props must be serialized to cross this boundary.
- Functions, class instances, and complex objects cannot be serialized. Stick to plain JSON data.
Done with this concept?
Mark it complete to track your progress. No login needed.