# react-jsonschema-form: rendering React forms from a JSON Schema

> RJSF turns a JSON Schema document into a React form, with a validator package and a theme package deciding how the fields look. It fits teams that already own a schema; it is a poor fit for people who want to draw a form by hand.

**rjsf-team/react-jsonschema-form** — A React component for building Web forms from JSON Schema.

- Repository: https://github.com/rjsf-team/react-jsonschema-form
- Website: https://rjsf-team.github.io/react-jsonschema-form/
- Stars: 15,908 · Forks: 2,340
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/rjsf-team-react-jsonschema-form

## What react-jsonschema-form solves, and for whom

The problem is duplication between a data contract and a form. If a service already publishes a JSON Schema describing a payload, a hand-written React form is a second copy of that structure, and the two drift. react-jsonschema-form removes the second copy: the README describes it as "a simple React component capable of using JSON Schema to declaratively build and customize web forms." The schema is the input, the form is the output.

The audience is narrow and specific. It is engineers who receive schemas from somewhere else (an API, a config format, a backend team) and need a UI for them without writing a field per property. It is also teams building internal tools where the schema changes more often than the UI code should. It is not aimed at designers who want pixel control over each input, and it is not aimed at a single contact form with four fields.

The repository is a monorepo, and package.json describes it as "monorepo for react-jsonschema-form and its themes." That word matters. The React component is not the whole product; the themes and the validator packages are first-class parts of the same repo, and choosing among them is part of adopting it.

## The schema-to-form pipeline and why the validator is a separate package

The architecture visible in the README splits the work into three kinds of package. The core renders. A validator package checks values against the schema. A theme package supplies the actual input components.

The README lists four validator packages: @rjsf/validator-ajv8, @rjsf/validator-ata, @rjsf/validator-cfworker and @rjsf/utils. The names are informative. Ajv is the long-standing JSON Schema validator for JavaScript, so validator-ajv8 is the general-purpose choice. validator-cfworker is named for Cloudflare Workers, which suggests an edge-runtime target where a different bundle or environment is needed. validator-ata is a third option whose behaviour the README does not describe. @rjsf/utils is listed under the same heading, which tells you shared utilities live there rather than in core.

This separation is the design decision worth understanding. Validation is not baked into the renderer. You pass a validator in, and the component uses it. The practical consequence is that JSON Schema is a large specification with optional vocabularies, and different validators support different parts of it. The form can render a construct that the validator then rejects, or accept one it never checks. The README does not document per-validator keyword coverage, so that gap has to be closed by reading the individual package pages.

Themes work the same way. The README lists ten supported themes, including Ant Design v5, Bootstrap v3 in core, Chakra UI v3, Daisy UI v5, Fluent UI v9, Mantine, Material UI v7, React-Bootstrap for Bootstrap v5, Semantic UI v2 and Shad CN. Each is a separate package under packages/. The core entry is labelled Bootstrap v3, so the default rendering is a Bootstrap 3 look, not an unstyled one.

## Installing react-jsonschema-form and rendering a first form

The README does not include an install snippet, so there is nothing to copy for the install step. What the README does give is the package list under API Libraries: @rjsf/utils, @rjsf/validator-ajv8, @rjsf/validator-ata and @rjsf/validator-cfworker, alongside the theme packages under Supported Themes. The repository's package.json shows the project is managed with pnpm (pnpm-lock.yaml, pnpm-workspace.yaml) and requires Node >=20 under engines.

The fastest way to see what a schema renders is the live playground the README links on GitHub Pages at https://rjsf-team.github.io/react-jsonschema-form/. The README does not print a usage example, so the shape of the React component has to come from the docs site rather than from this repository's README.

To work on the library itself rather than consume it, the root package.json exposes nx-driven scripts. The build target and the test target are the two you will run first, and the start script deliberately does not launch a dev server at the root.

```bash
pnpm run build
pnpm run test
```

The start script prints a message rather than starting anything: "use \"pnpm run build\" from main directory and then \"pnpm start\" in the playground package". So the playground is a separate package you run after building the workspace, not a root-level dev command.

## Where the declarative approach stops paying off

Schema-first forms have a ceiling, and it sits exactly where the schema stops describing what the user needs to see.

Layout is the clearest case. A JSON Schema describes data shape, not visual arrangement. Anything that requires fields side by side, grouped into steps, or shown conditionally on a value the schema does not model has to be expressed through the library's own extension points rather than through the schema. The README does not document those extension points; it points to the docs site. The related searches include "react jsonschema form conditionals" and "react jsonschema form drag and drop", which suggests these are the questions people arrive with, and neither is answered by the README itself.

The second cost is the validator coupling. Because validation is a separate package, the set of schema keywords your form enforces depends on which validator you installed. A schema using a keyword your validator ignores will render a field that never fails validation. That is a silent failure mode, not a loud one, and it will not appear until a downstream consumer rejects the data.

The third cost is the theme. Ten supported themes is a lot of surface to keep current. If your design system is not on the list, you are writing a theme package, which is a larger commitment than writing a form. And if you are on Bootstrap 3 through core while the rest of your app moved on, you are carrying a second styling system for one screen.

## JSON Forms and the difference in where the schema lives

The obvious alternative is JSON Forms, which the related searches pair against this project ("React jsonschema form vs jsonforms"). The difference in approach is worth stating precisely, because it changes what you write.

react-jsonschema-form generates the form from the schema. The schema is the single source, and the UI follows it. JSON Forms separates the data schema from a UI schema, so the data contract and the layout are two documents that you author together. That means more files to maintain and a clearer place to put layout decisions.

Which is better depends on whether the schema is yours. If a backend team publishes the schema and you cannot add layout hints to it, generating from it is the only option, and the extra document JSON Forms wants becomes a maintenance burden. If you control both and know the form needs a specific arrangement, splitting layout into its own document is honest about the fact that layout is not derivable from data shape. The trade-off is real in both directions, and the related search phrase "react jsonschema form alternative" is usually someone discovering that their layout requirements do not fit the generated model.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-20. Recent releases are v6.10.1 on 2026-09-16, v6.10.0 on 2026-09-09 and v6.9.0 on 2026-08-30. That is a steady release cadence at the patch and minor level, and the version numbers tell you the project is past a major boundary, so a 6.x to 7.x jump is the kind of change that would carry migration work. The CHANGELOG.md at the repository root is where that work would be described; the README does not document upgrade paths or breaking changes.

The licence is Apache-2.0, declared in package.json and shown as a badge in the README. Apache-2.0 is a permissive licence that includes an explicit patent grant, which matters more for a UI dependency shipped inside a commercial product than the MIT-versus-Apache distinction usually suggests. It does not require you to publish your own source. This is a description of the licence text, not legal advice; if the patent clause or notice requirements affect your distribution, that is a question for your own counsel.

The upgrade cost that is easy to miss is the theme packages. Because the monorepo ships ten of them and each tracks an upstream design system (Ant Design v5, Material UI v7, Fluent UI v9), an upgrade of react-jsonschema-form can be blocked by a major version of the design system it targets. If your app is pinned to an older Material UI, the matching RJSF theme may not be available at the version you want.

## Conclusion

Adopt react-jsonschema-form when a JSON Schema already exists as the contract for your data and the form is one view of it. Do not adopt it when the form is the product and the schema would be reverse-engineered from the UI. Before committing, verify three things: that the validator package you pick matches your runtime, that the theme you want is listed in the README's supported themes, and that the JSON Schema keywords your documents use are handled by that validator, since the schema vocabulary and the validation library are separate choices.

## FAQ

### What is a JSON Schema?

The README points to json-schema.org as the specification behind the library. It is the document format that describes the shape of JSON data, and in this project it is the input that the React component turns into a form.

### What is the difference between JSON and JSON Schema?

JSON is the data itself; a JSON Schema is a separate document that describes what that data is allowed to look like. react-jsonschema-form consumes the schema, not the data, and generates the fields from it.

### What are React forms and how do they work?

React forms are components that hold input state and handle submission. react-jsonschema-form is one such component: the README describes it as a React component that uses JSON Schema to declaratively build and customize web forms.

### How does react-jsonschema-form compare with JSON Forms?

react-jsonschema-form generates the form from a single JSON Schema. JSON Forms separates the data schema from a UI schema, so layout is authored as a second document rather than derived from the data shape.

### Does react-jsonschema-form support drag and drop?

The README does not document drag and drop, and it points to the docs site for behaviour beyond the package list. Treat it as unconfirmed until you find it in the documentation.

## Sources

- [License: Apache-2.0](https://github.com/rjsf-team/react-jsonschema-form/blob/main/LICENSE)
- [Project website](https://rjsf-team.github.io/react-jsonschema-form/)
- [README](https://github.com/rjsf-team/react-jsonschema-form/blob/main/README.md)
- [Releases](https://github.com/rjsf-team/react-jsonschema-form/releases)
- [rjsf-team/react-jsonschema-form on GitHub](https://github.com/rjsf-team/react-jsonschema-form)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rjsf-team-react-jsonschema-form