json-edit-react puts a writable JSON tree into a React application

A component, not a page

json-edit-react is a highly configurable React component for editing or viewing JSON and object data. The package description in its metadata is short, and it is the right description: this is a component you drop into a form or a settings screen, not an application.

The audience is a React developer who has to show a JSON payload to a user and let them change it. That is a specific enough problem that the feature list reads like a specification for it. Inline editing of individual values or whole blocks of JSON text, granular control that restricts edits, deletions or additions per element, JSON Schema validation through a third party validation library, a customisable UI with built-in or custom themes, CSS overrides or targeted classes, and a search and filter facility that can find data by key, by value or by a custom function.

Two structural promises matter when you are choosing a dependency. The package is self-contained, built on plain HTML and CSS with no external UI library dependencies, and it has zero runtime dependencies. For a component that ends up in somebody else's bundle, that is the argument that decides it.

The project is MIT licensed, authored by Carl Smith, with the demo hosted at carlosnz.github.io/json-edit-react. The last push was on 2026-10-10, and the release cadence is quick, with v2.0.4 on 2026-10-03, v2.0.3 on 2026-10-02 and v2.0.2 on 2026-09-30.

Two components and exactly two required props

The implementation section of the documentation is the whole integration story, and it fits in one snippet:

import { JsonEditor } from 'json-edit-react'

// In your React component:
return (
  <JsonEditor
    data={ jsonData }
    setData={ setJsonData }
    { ...otherProps } />
);

Two props are required, data and setData, which tells you the model immediately. The component is controlled, your application owns the data and receives the updated object through the setter. There is no internal copy that has to be reconciled, which is the right choice in React and also means the component is easy to drive from outside.

For a read-only case, there is a separate component:

import { JsonViewer } from 'json-edit-react'

return <JsonViewer data={ jsonData } { ...otherProps } />

JsonViewer takes data only, with no setter, and the props reference states plainly that for a read-only component you should use JsonViewer instead. That distinction is worth respecting, because an editor with editing affordances and a viewer without them are different products and the library ships both.

The rest of the props are optional, and the documentation is organised so that each feature area has its own section, including a props reference, managing state, filter functions, controlling editing, reacting to changes, appearance and theming, initial expansion, search and filtering, localisation, keyboard control, custom nodes and components, overriding and extending the UI, programmatic control, performance considerations, undo functionality and exported helpers and types.

The interaction model is more than clicking edit

The section on using the editor is aimed at end users rather than developers, and it is the best evidence of how the component actually behaves.

Editing starts with a double-click on a value or a key. When editing a string, Cmd or Ctrl with Enter, or Shift with Enter, adds a new line, while Enter submits the value. For a full object or array node, which you open with the edit icon, the keys are reversed, Enter adds a new line and the modifier combination submits. Escape cancels.

The clipboard icon has a hidden mode. Holding Cmd or Ctrl while clicking it copies the path to the selected node rather than its value, which is the difference between a copied string and a copied location in the document.

Structure navigation has shortcuts too. Alt or Option while opening or closing a node opens or closes all child nodes at once, and Tab and Shift-Tab move between values while editing. For number inputs the up and down arrows increment and decrement the value, and for boolean inputs the space bar toggles it.

Two behaviours are about display rather than editing. Drag and drop reorders items to change the structure or the display order, and when editing is not permitted, double-clicking a truncated string expands it to the full value, with a clickable ellipsis for long strings.

There is also an escape hatch for input parsing. The JSON text input can accept looser input if an additional JSON parsing method is provided, for example JSON5, through the jsonParse prop.

Permissions, schema validation and custom nodes

The granular control feature is what separates this from a generic JSON textarea in a React app. You can restrict edits, deletions or additions per element, so a user can change a display name but not an identifier, and the component will not offer the operation that is not allowed.

Schema validation is present but it is not the component's own work. The feature list attributes it to a third party validation library, which means you supply the validator and the schema, and the component wires validation results into the editing experience. The same separation of concerns shows up in the custom nodes feature, where keys and values can be replaced with specialised components, with the documentation naming date picker, links, images, undefined, BigInt and Symbol as examples.

The optional companion packages extend the same idea. There is a themes package with curated ready-made themes, a components package with custom node components such as links and a date picker, and a utilities package described as a collection of helpers for extending and streamlining the experience. Splitting them out means the core package stays small, which fits with the self-contained and zero dependency claims.

Localisation is handled by translating the UI labels and messages, and keyboard customisation lets you define your own key bindings rather than living with the defaults. External control is available through callbacks and imperative methods, for a parent that needs to drive the editor rather than react to it.

Version 2 is a rewrite with its own migration guide

The most important thing in the documentation is a warning at the top. This documentation is for version 2 of json-edit-react, version 1 has its own documentation and its own demo, and anyone upgrading is told to read the migration guide, which lives in the repository as migration-guide.md.

That framing tells you the scale of the change. A V1 to V2 upgrade is not a dependency bump, it is a component swap, and the repository keeps a README_V2.md alongside the main README to hold the new documentation.

The build system reflects a package that is taken seriously as a library. The package is built with rollup into a CommonJS build at build/index.cjs.js, an ES module build at build/index.esm.js and type declarations at build/index.d.ts, with the stylesheet exposed as a separate export at ./style.css. The sideEffects field lists that stylesheet, which tells a bundler that the rest of the package can be tree-shaken safely. The build script does more than compile, it removes the generated declaration folder and then runs a script that verifies tree-shaking, and the prebuild step runs the linter and a set of prebuild tests.

The repository is a pnpm workspace with a packages/ directory, a demo application built with Vite, a test directory, and separate configurations for jest and for a benchmark run. The publish flow is a two stage one, where a script stages the package into a build_package directory before pnpm packs it, and the compile script runs tsc in noEmit mode together with ts-prune to find unused exports.

Where this component is the wrong choice

The honest limitations are mostly about scope and about the rewrite.

If you only need to display a JSON payload, an editor is the wrong tool even when the library provides a viewer. A read-only display is a formatting problem, and shipping an editable tree with a full interaction model, keyboard handling, undo support and search for a static view is paying for features you will not use. The library does provide JsonViewer for exactly that reason, but the component set still arrives as a package.

The second limit is the dependency question in the other direction. JSON Schema validation is delegated to a third party library that you have to bring, which is the right design for a zero dependency package and the wrong one if your application already commits to a specific validator, because you will be asked to fit two.

The third is the beta of a rewrite. Version 2 was a substantial change with a migration guide, and the releases since have been patch-level and rapid, which suggests a young and actively changing API surface. The documentation itself lists performance considerations and undo functionality as their own sections, which tells you those are areas where behaviour is worth reading about rather than assuming.

The companion packages are also a decision. Themes, custom components and utilities are separate installs, so a project that wants all three is assembling a small ecosystem rather than adding one dependency, and the versions of those packages have to move with the core.

Editorial conclusion

json-edit-react suits a React product that needs to show a user an object and let them change parts of it safely, and it is the wrong tool for a read-only display, where JsonViewer or plain markup is enough, or for a project that cannot take on a major rewrite. Before adopting it, read the V1 to V2 migration guide, because the package was rewritten for version 2, and decide up front whether the third party JSON Schema validation library is acceptable in your bundle.

Frequently asked questions

Official sources

1. CarlosNZ/json-edit-react on GitHub
2. License: MIT
3. Project website
4. README
5. Releases