# rsc-parser opens up the React Server Component wire format

> rsc-parser is an MIT licensed tool for reading the payloads React Server Components send over the network, shipped three ways as a Chrome extension, an embedded React panel and a paste site, and it is built around a monorepo of three npm packages.

**alvarlagerlof/rsc-parser** — A parser for the React Server Components when sent over the network

- Repository: https://github.com/alvarlagerlof/rsc-parser
- Website: https://rsc-parser.vercel.app
- Stars: 666 · Forks: 18
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/alvarlagerlof-rsc-parser

## The wire payload is JSON-shaped but not JSON

React Server Components travel as a text format that resembles JSON without being it. The documentation describes a payload as looking roughly like JSON, but with each line starting with something like O:, 1:I or b:. Those prefixes are the format's own type markers, and they are the reason an ordinary JSON parser is not enough.

What the payload carries is described in the README as a tree of components and html, or metadata such as required imports, suspense boundaries, and css or fonts that need to be loaded. That is the payoff of the tool. A component tree that React has already resolved is not visible in the browser DOM, because the server sent instructions rather than finished markup, so the interesting state of an application is often exactly the state you cannot inspect with a normal inspector.

The stated motivation is practical rather than academic. The author built the tool to make it easier to understand the data and to explore it visually, and the project publishes a comparison page showing the two views side by side.

## Three channels, and they are not interchangeable

The project is delivered in three forms, and picking between them is really a question of where the payload lives.

The Chrome extension is the widest-reaching option and the least integrated. It attaches to a site you are already visiting, so it works on a Next.js App Router application or anything else based on React Server Components without changing a line of that application's code. Its limit is that it lives in one browser, on one site at a time.

The npm package is the deepest option. Adding it to your project gives you an embedded panel component that you render in a layout.tsx, which means the panel sits inside your own application, sees only your payloads, and is available to anyone who can open your development environment.

The website is the narrowest and the most portable. You manually copy a payload and paste it into a form, and nothing is installed anywhere. For a bug report or a colleague's snippet, that is the fastest route, and it is the only one that works when you cannot modify the application that produced the payload.

## Adding the embedded panel to a layout

The install step given in the documentation is a single add command with the embedded package:

`bun add @rsc-parser/embedded`

The panel itself is a React component loaded lazily and rendered inside a Suspense boundary, and the README example shows it wired into a root layout:

```tsx
import { Suspense, lazy } from "react";

const RscDevtoolsPanel = lazy(() =>
  import("@rsc-parser/embedded").then(module => ({
    default: module.RscDevtoolsPanel,
  })),
);
```

Two details in the example are worth copying rather than paraphrasing. The import is dynamic, so the panel code is only fetched when it renders, and the export is remapped to the default export, which is the shape lazy expects. The example also gates rendering on a condition, and the comment in the source says to use any condition or flag you want there, with the shown condition being process.env.NODE_ENV equal to development.

That gate is a decision to make on purpose. A panel that renders for every visitor in production is a different product from one that appears for developers, and the example is a suggestion rather than a documented policy.

## Getting a payload out of the network tab

The paste workflow is a documented procedure rather than a feature, and it is the most useful part of the documentation for someone who does not control the application.

The steps are short. Open a site that uses the NextJS App router or is generally based on React Server components, open the network tab in your dev tools, and reload. Then look for fetch responses whose payload roughly looks like JSON but whose lines start with markers like O:, 1:I or b:. Copy that text and paste it into the form on the website, then explore it.

The identification step is the fragile one. A response can look like JSON in a dev tools preview and still be the wrong thing, and the format does not announce itself with a content type you can filter on in the UI. The prefix markers are the reliable signal, and the documented instruction to look for fetch responses with those line prefixes is the practical way to filter the noise.

The website at rsc-parser.vercel.app does the parsing on pasted text, so nothing about the target application is sent anywhere until you paste it.

## A monorepo of three published packages

The repository is a workspace monorepo. The root package.json declares workspaces of packages/* and examples/*, names the package manager as bun@1.4.3, and drives every task through turbo, with scripts for build, clean, lint, test, typecheck, format, ci and dev. An examples/embedded-example directory holds a working usage of the embedded package.

Three packages are published to npm: @rsc-parser/core, @rsc-parser/embedded and @rsc-parser/react-client. The split is functional rather than arbitrary. The core package holds the parsing, the embedded package is the panel you render in a layout, and the react-client package is the piece that talks to a running client. The version numbers are kept in step: all three were published at 1.1.2 on 2025-05-09, within seconds of each other, which is what a coordinated release looks like.

Releases are managed with changesets. The version script runs changeset version followed by a shell script named apply-version.sh, and the release script runs changeset publish. Renovate is configured at the root for dependency updates, and a knip script exists to find unused code.

## When the parser gives up, the fix is to send it the text

The documentation has a short section for the case where the parser cannot handle a payload. It asks you to open an issue on the project's issue tracker and include the text content that the parser was unable to handle.

That is an admission worth taking at face value. A RSC payload is generated by whatever version of React and whatever framework version produced it, and the format has more room to vary than a stable wire protocol. The project's answer is to accumulate the unparseable examples and extend the parser, which is a workable but manual loop: the reporter has to extract the payload, and the maintainer has to reproduce the failure from the pasted text alone.

So the practical limit is clear. If a payload cannot be parsed, this tool gives you no partial view and no error taxonomy, it asks for a bug report. Teams that need guaranteed coverage of every payload shape are looking at a dependency they do not control, and the last published version of all three packages dates from 2025-05-09.

## MIT terms, an unversioned release trail, and a busy branch

The licence is MIT, declared in the root package.json and in the LICENSE file at the repository root. The maintainer is Alvar Lagerlöf, and the project is published under the name rsc-parser with a private flag on the root package, which is normal for a monorepo root that exists only to host the workspaces.

The release picture is where a reader should slow down. The three most recent releases are @rsc-parser/react-client@1.1.2, @rsc-parser/embedded@1.1.2 and @rsc-parser/core@1.1.2, all published on 2025-05-09. The repository is not archived and the last push was on 2026-10-20, so the branch is being worked on, but no new package version is attached to that work.

That gap between the published packages and the pushed branch is the upgrade cost to plan for. The packages are versioned together and published together, which is convenient, but the npm versions you install are more than a year older than the repository state, and the changesets workflow means unreleased changes accumulate in the repository rather than in your node_modules. Pin the exact version, check what the branch contains before assuming it is in the published packages, and keep the MIT terms in mind if you intend to build the panel into a product you distribute.

## Conclusion

rsc-parser fits a team debugging a Next.js App Router application that needs to see the server component tree, the suspense boundaries and the required imports that never appear in the rendered DOM, and the embedded panel is the only one of the three channels that works inside your own deployment. It does not fit a production incident where the payload cannot be captured, since a parse failure only produces an issue asking for the raw text. Before adopting it, try the paste site with one of your own payloads, check the three published packages are at the same version, since the last release of each was 1.1.2 on 2025-05-09 while the repository was pushed to on 2026-10-20, and decide whether the embedded panel is gated behind the development flag in your layout.

## FAQ

### How do I install the rsc-parser embedded panel?

The documentation gives the command bun add @rsc-parser/embedded, then shows the panel being imported lazily and rendered inside a Suspense boundary in a layout.tsx. The example gates the panel on a condition, with process.env.NODE_ENV equal to development used as the sample.

### How do I find a React Server Component payload to paste into rsc-parser?

Open the network tab in your dev tools, reload the site, and look for fetch responses whose text looks roughly like JSON but whose lines start with markers such as O:, 1:I or b:. Copy that text and paste it into the form on the website.

### What happens when rsc-parser cannot handle a payload?

The documentation asks you to open an issue on the project tracker and include the text content the parser was unable to handle, so the case can be reproduced and the parser extended.

### Which packages does rsc-parser publish and what version are they on?

Three npm packages are published: @rsc-parser/core, @rsc-parser/embedded and @rsc-parser/react-client. All three were published at version 1.1.2 on 2025-05-09.

### Is there a browser extension for rsc-parser?

Yes. A Chrome extension is published on the Chrome Web Store, called RSC DevTools, and it attaches to sites built on React Server Components without any change to the site itself.

## Sources

- [alvarlagerlof/rsc-parser on GitHub](https://github.com/alvarlagerlof/rsc-parser)
- [License: MIT](https://github.com/alvarlagerlof/rsc-parser/blob/main/LICENSE)
- [Project website](https://rsc-parser.vercel.app)
- [README](https://github.com/alvarlagerlof/rsc-parser/blob/main/README.md)
- [Releases](https://github.com/alvarlagerlof/rsc-parser/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/alvarlagerlof-rsc-parser