# json-editor/json-editor: A JSON Schema to HTML Form Generator in Maintenance Mode

> json-editor/json-editor turns a JSON Schema into a working HTML form, with no runtime dependencies and optional integrations for Bootstrap, Tailwind and Spectre. The README now states the library is in maintenance mode, with active development moved to Jedison.

**json-editor/json-editor** — JSON Schema Based Editor

- Repository: https://github.com/json-editor/json-editor
- Stars: 4,903 · Forks: 698
- Language: JavaScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/json-editor-json-editor

## What json-editor/json-editor actually generates

The project takes a JSON Schema and uses it to generate an HTML form. That is the whole contract. Instead of hand-writing inputs, labels and validation attributes for every field, you hand the library a schema document and it produces the DOM. The README states full support for JSON Schema version 3 and version 4.

The audience is narrow but real. If your application already stores configuration, survey definitions, API payloads or anything else as JSON Schema, this library closes the gap between that document and a form a human can fill in. It is a browser library, not a server-side validator. The README says it has no dependencies and only needs a modern browser, tested in Chrome and Firefox. Everything else in the optional requirements list, from Mustache and Handlebars to Bootstrap and Tailwind, is styling or editor enhancement layered on top.

The project is a fork. The README describes it as a fork of the inactive jdorn/json-editor using the updated fork json-editor/json-editor, with some pull requests added from the original repository. That history matters when you evaluate the codebase: parts of the design date from an earlier era of JavaScript tooling, and the repository carries a UPGRADING.md file, which suggests breaking changes between versions have needed migration notes.

## How the schema becomes a form at runtime

Initialization is two lines. You give the library a DOM element and an options object, and it builds the form inside that element.

```js
const element = document.getElementById('editor_holder');

const editor = new JSONEditor(element, options);
```

Options can be set globally on JSONEditor.defaults.options or per instance at construction time. The README shows setting a theme globally with JSONEditor.defaults.options.theme = 'bootstrap4' and the same key passed into the constructor options. That global-versus-instance split is the main configuration axis: theme, icon library, template engine and the various optional editor integrations are all selected through it.

The data flow is schema in, form out, JSON back. The README's own diagram sums it up as JSON Schema to HTML Editor to JSON. One option worth noting is ajax, which defaults to false. When it is true, the README says JSON Editor will load external URLs in $ref via ajax. That is the mechanism for splitting a schema across files, and it is off by default, so a schema that references remote definitions will not resolve until you enable it. A related option, ajaxBase, lets schema references work relative to a base path.

Optional integrations are resolved at runtime rather than bundled. If you want a signature pad, a color picker, a Markdown editor or a nicer select box, you load that third-party library yourself and the editor picks it up. The README lists SCEditor, SimpleMDE, Ace, Jodit, Flatpickr, Signature Pad, Vanilla Picker, Cleave.js, IMask.js, Choices, Select2, Selectize, math.js and DOMPurify among them. This keeps the core small, but it also means the quality of a given field type depends on a library the project does not maintain.

## Installing json-editor/json-editor and rendering a first schema

The package is published as @json-editor/json-editor. The README gives the npm install command directly.

```bash
npm install @json-editor/json-editor
```

If you would rather not run a build step, the README also documents a CDN script tag pointing at the minified distribution.

```bash
<script src="https://cdn.jsdelivr.net/npm/@json-editor/json-editor@latest/dist/jsoneditor.min.js"></script>
```

The README notes that older releases are available from the same CDN landing page, and that you can download the production or development build locally if you prefer to serve the file yourself. The package main entry is dist/jsoneditor.js, so a bundler that respects the main field will pick up the built file rather than the src directory.

Once the script is loaded, construct an editor against a container element and pass your schema in the options. The README's example options object is where schema, theme and startval would go; the two-line constructor above is the exact shape it documents. What you should see is a rendered form inside the container element, with fields derived from the schema. If the form is empty, the usual cause is a container that does not exist yet when the constructor runs, or a schema that failed to parse.

For a working reference before you write your own, the README points at an interactive demo, a form submission case study, and a separate playground hosted at pmk65.github.io/jedemov2/dist/demo.html. That playground is the fastest way to see which editor types a given schema produces.

## Maintenance mode is the constraint that shapes adoption

The README opens with a maintenance mode notice, and it is explicit about what that means. The library remains stable and functional, but active development has moved to Jedison. The maintainers say they will continue to accept and review community pull requests, address critical bugs and security issues, and keep the library functional for existing users. They also state that new projects, or those seeking active development, should consider Jedison.

Read that as a bounded commitment. Bug fixes for critical and security issues are in scope. New editor types, new framework themes and performance work are not. If your schema uses a construct the library handles awkwardly today, a pull request may be reviewed, but there is no roadmap promising it will land.

The repository itself is not archived, and the last push was on 2026-08-25, so the code is not frozen. That does not contradict the maintenance notice; it means review and small fixes are still happening. The distinction matters if you are comparing this project against something abandoned. This is a maintained-in-place library, not a dead one, and the maintainers have said so in the README rather than leaving you to infer it.

The practical consequence is version pinning. With no release cadence to plan around, you should treat the version you install as the version you will run, and read UPGRADING.md before moving between major versions.

## Where json-editor/json-editor is the wrong choice

The clearest failure case is a project that needs a form generator with an active feature roadmap. The README itself redirects that audience to Jedison. Choosing this library anyway means accepting that new capabilities arrive only if someone in the community contributes them.

A second case is server-side rendering. This is a browser library that manipulates the DOM. The README's requirements section talks about modern browsers, not Node rendering pipelines. If you need a form rendered to HTML on the server, you are using the wrong tool.

A third is schemas that lean on JSON Schema drafts beyond version 3 and 4. The README claims full support for those two versions and says nothing about later drafts. If your schema uses keywords from a newer draft, do not assume they are honored.

There is also a dependency-quality caveat that the README does not frame as a limitation but functions as one. Many of the richer field types depend on optional third-party libraries: Ace for code, SimpleMDE for Markdown, Signature Pad for signatures, Choices or Select2 for select boxes. Those libraries have their own maintenance status, and the README does not document what happens when one of them changes its API. If you rely on a specific editor type, that third-party library is part of your dependency surface whether or not it appears in package.json.

## Alternatives and the difference in approach

The alternative the project itself names is Jedison, at github.com/germanbisurgi/jedison. The README describes it as where active development has moved. The difference is not in the output, which is still a form generated from a schema, but in the maintenance posture: Jedison is the codebase receiving new work, while json-editor/json-editor receives pull request review and critical fixes. If your decision hinges on future feature availability, that is the deciding difference.

A different kind of alternative is not using a schema-driven generator at all. If your forms are few and stable, hand-written HTML with a validation library is smaller and has no upgrade path to manage. The trade-off is the one this project exists to remove: keeping form markup and validation in sync with a schema document by hand. That cost grows with the number of schemas and the frequency of schema changes, and it is close to zero for a single static form.

A third option, for teams already inside a component framework, is a framework-specific form library. The README does not discuss React, Vue or similar integrations, so there is nothing here to compare against on that axis. The relevant question is whether you want a schema document to be the source of truth for the form. If yes, a schema-driven generator is the right category, and the choice within it comes down to maintenance posture.

## Licence and the cost of staying on this version

The project is MIT licensed. That is permissive: you can use it commercially, modify it and redistribute it, provided the licence and copyright notice are preserved. Nothing in the README adds field-of-use restrictions or a commercial tier. This is a description of the licence identifier, not legal advice; read the LICENSE file in the repository for the binding text.

The upgrade cost is the part teams underestimate. The repository ships an UPGRADING.md, which signals that version transitions have required code changes in the past. Combined with a maintenance-mode posture, the sensible operating model is to pin an exact version and budget time for reading UPGRADING.md only when you deliberately move. There is no release cadence to ride.

The other ongoing cost is the optional integration surface. Every third-party editor library you enable, from Ace to Select2, is something you will eventually have to update or replace independently of this project. The README does not track those versions for you. If you enable three of them, you own three upgrade paths that the maintainers of this library do not control.

## Conclusion

Adopt json-editor/json-editor when you already have JSON Schema documents and need a browser form that stays in sync with them, and when you can accept a library whose README says it is in maintenance mode with active development moved elsewhere. Do not adopt it for a greenfield project that expects new features or a roadmap; the README points new projects at Jedison instead. Before committing, verify the exact @json-editor/json-editor version you install, confirm the theme you need (bootstrap4, spectre or tailwind) is present in that version, and check that the editor types your schema relies on behave as expected in Chrome or Firefox, the two browsers the README names as tested.

## FAQ

### How do I install json-editor/json-editor?

The README gives the npm command npm install @json-editor/json-editor. It also documents a CDN script tag pointing at dist/jsoneditor.min.js on jsdelivr, and notes that older releases are available from the same landing page.

### How do I use json-editor/json-editor in a page?

The README's example gets a container element by id and calls new JSONEditor(element, options). Options can be set globally on JSONEditor.defaults.options or passed per instance, which is how you select a theme such as bootstrap4.

### Is json-editor/json-editor still maintained?

The README states the library is in maintenance mode. The maintainers say they will accept and review community pull requests, address critical bugs and security issues, and keep it functional for existing users, while active development has moved to Jedison.

### Which JSON Schema versions does json-editor/json-editor support?

The README states full support for JSON Schema version 3 and version 4. It does not claim support for later drafts.

### Can json-editor/json-editor load a schema from another file?

Yes, through the ajax option, which the README says defaults to false. When set to true, JSON Editor will load external URLs in $ref via ajax, and the ajaxBase option lets schema references work relative to a base path.

## Sources

- [Issues](https://github.com/json-editor/json-editor/issues)
- [json-editor/json-editor on GitHub](https://github.com/json-editor/json-editor)
- [License: MIT](https://github.com/json-editor/json-editor/blob/master/LICENSE)
- [README](https://github.com/json-editor/json-editor/blob/master/README.md)

---

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