JSON Forms: JSON Schema forms for React, Angular and Vue

The problem JSON Forms solves: one schema, three frameworks

Most form libraries assume you will write the form. JSON Forms assumes you will write the data definition. You supply a JSON Schema describing the shape of the data and a separate UI schema describing how to arrange it, and the library produces the form. The README states the pitch directly: "Complex forms in the blink of an eye." The audience is teams with many forms over similar data, or teams whose forms come from a backend contract that changes. When the schema changes, the form follows.

The second half of the problem is framework churn. The repository ships renderer packages for React, Angular and Vue, and the topics list includes angular, react and vue3. If the same product has a React web client and an Angular admin console, the form definition is portable between them. That is the real differentiator. A single-framework form library solves the same rendering problem but ties the definition to that framework's component model.

How JSON Forms splits data, layout and rendering

The architecture has three inputs. The data is a plain JSON object. The schema is JSON Schema. The UI schema is a separate JSON document that controls which properties appear, in what order, and inside which layout elements. Splitting the two schemas is the design decision everything else follows from. JSON Schema can express that a field is a string with a maximum length, but it has no vocabulary for "put this in the right column next to the address block." The UI schema carries that.

Rendering then goes through a registry of renderers. Each renderer declares what it can handle, and the library picks the matching one for a given schema and UI schema combination. That is why the repository is a monorepo with a packages directory: the core logic is framework-independent, and each framework package supplies the binding plus a set of renderers. The renderer sets named in the repository are the vanilla and Material variants for React, Angular Material, and Vue Vanilla and Vue Vuetify. Choosing a renderer set is a real decision, not a cosmetic one, because Material renderers pull in a component library you may not otherwise use.

The package layout also tells you what is not there. The README points at jsonforms.io for documentation, examples and API references, which means the repository itself is thin on usage guidance. The README does not document rollback or error recovery behaviour, so plan to read the site before assuming how validation failures surface.

Installing JSON Forms through the React seed app

The README does not give a bare npm install line. It points you at a seed application, which is the fastest way to see the pieces wired together. The three steps are clone, install, run:

git clone https://github.com/eclipsesource/jsonforms-react-seed.git
npm ci
npm run start

The seed's own README covers the details, and jsonforms.io/docs/tutorial goes further. What you should see is a working React app with a rendered form. Read the seed's package.json to learn which @jsonforms packages it depends on, because that mapping is what you will replicate in your own project.

If you want to work on the library itself rather than consume it, the developer setup is different and stricter. Node v24+ below v25 is the supported range, and pnpm 11 or newer is required, either installed directly or enabled through corepack. The root package.json encodes both constraints:

{
  "engines": {
    "node": "^24",
    "pnpm": "^11"
  },
  "packageManager": "[email protected]+sha512.a81d4c21b9b09a4b0aebf90ef5e527d4262bdda322d26082978cb549023ac6d9cafc98b19fffaa5c71db438a65f70224edb78d7311187861ff96480d1cdca23c"
}

After cloning the monorepo, install with pnpm i --frozen-lockfile. Build everything with pnpm run build and test with pnpm run test. To poke at a specific renderer set interactively, the README lists per-package dev commands, for example cd packages/material-renderers && pnpm run dev, or cd packages/vue-vuetify && pnpm run dev. There is also a VS Code dev container configured in devcontainer.json; the README warns that installing dependencies before opening the container can break its initialization, and suggests git clean -dfx as a remedy, noting that this deletes untracked files.

Where JSON Forms gets in your way

The two-schema model is the main cost. Anyone on the team who wants to add a field must touch the schema and the UI schema, and understand which of the two controls what. For a five-field contact form, that is more ceremony than writing JSX or an Angular template. JSON Forms earns its keep at scale, not at the first form.

The renderer registry is the second cost. The framework packages ship renderer sets, but the moment your design system differs from the shipped ones, you write custom renderers and register them. That is an extension point, not a bug, but it means adoption is a small engineering project rather than a dependency bump. Budget for it.

The third cost is version migration. The repository carries a MIGRATION.md and the README links it for anyone updating JSON Forms. A migration guide existing at all is a signal that upgrades are not always drop-in. Check it against the version you are moving to before you plan the work.

Finally, the repository is a monorepo built with pnpm and lerna, and the supported Node range is narrow. If your build environment is pinned to an older Node release, you are outside the stated support window. The last push was on 2026-09-22, and the most recent release listed is v3.8.0 from 2026-06-16.

JSON Forms vs rjsf and react-jsonschema-form

The closest comparison is rjsf, formerly react-jsonschema-form. Both take JSON Schema and produce a form, and both are React-first in origin. The difference is in what else they accept. Rjsf derives the form from the schema alone, with UI options attached to individual fields through a uiSchema that is closer to per-field configuration. JSON Forms separates the layout document from the schema more completely and, more importantly, is not tied to one framework: the repository ships React, Angular and Vue renderer packages, and the topics list names vue3 specifically.

So the choice is roughly this. If you are building a React-only product and want the shortest path from schema to form, rjsf's single-schema-plus-field-options approach has less to learn. If you need the same form definition to render in an Angular admin tool and a Vue customer portal, JSON Forms is the one with renderers for all three. The cost of that portability is the extra UI schema document and the renderer registration work described above.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-09-22. Releases are not frequent: v3.6.0 in June 2025, v3.7.0 in November 2025, v3.8.0 in June 2026. That cadence is worth knowing when you plan upgrades, because a fix you need may sit between releases rather than in one.

The licence is MIT, stated in the README and present as a LICENSE file at the repository root. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and licence text be preserved in copies. That is the general shape of the licence, not advice on your situation; have your own counsel read it if the distinction matters to you.

Support has two tiers visible in the README. Community help runs through GitHub issues and the JSON Forms board on Discourse, plus an email address. EclipseSource also offers professional support, linked from jsonforms.io/support. The ROADMAP.md file and the milestone structure in the README describe how issues are scheduled, including a Backlog milestone for things the maintainers do not plan to do themselves. That last detail matters: some issues are explicitly waiting on a community contribution or on a paying customer's prioritization.

Editorial conclusion

Adopt JSON Forms when the schema already drives your data model and you need the same form definition to render in more than one framework, and when someone on the team can write custom renderers. Skip it when you want a form builder that generates code you then own, or when your layouts are hand-tuned per screen and no schema exists yet. Before committing, check the migration guide for the jump to your target major version, confirm the renderer package for your framework and design system exists in the packages directory, and verify the Node version your build runs on against the engines field.

Frequently asked questions

Official sources

1. eclipsesource/jsonforms on GitHub
2. License: MIT
3. Project website
4. README
5. Releases