json-render: A Generative UI Framework for AI-Driven Interface Construction

What json-render Solves and Who It Is For

json-render addresses a specific problem in AI-assisted application development: when an AI model generates a user interface in response to a natural language prompt, the output is unpredictable unless it is constrained. A model that can emit arbitrary HTML or JSX will produce inconsistent, hard-to-validate, potentially unsafe markup. json-render solves this by requiring the model to output JSON that conforms to a schema derived from a component catalog the developer defines. The AI can only reference components that exist in that catalog, with props that match each component's schema.

The README states the three core properties: the AI can only use components in the developer's catalog (guardrailed), the JSON output matches the schema every time (predictable), and the spec can be streamed and rendered progressively as the model responds (fast). The target users are developers building applications where the UI needs to adapt to user input or context at runtime, such as AI chat interfaces that display structured data cards, dashboards that generate themselves from a natural language description, or form builders where the layout responds to a user's request.

This is a Vercel Labs project. The latest release at the time of the last push to the main branch was v0.21.0, published on 2026-09-18. The license is Apache-2.0.

The Catalog, Registry, and Spec Model

The framework's architecture has three layers. The catalog defines what components exist and what props each one accepts. The registry maps each catalog component to a concrete implementation in the target rendering framework. The spec is the JSON document the AI model generates at runtime, describing which components to render and with what props.

The README's Quick Start shows how the catalog is defined using defineCatalog from @json-render/core and Zod schemas for prop validation:

import { defineCatalog } from "@json-render/core";
import { schema } from "@json-render/react/schema";
import { z } from "zod";

const catalog = defineCatalog(schema, {
  components: {
    Card: {
      props: z.object({ title: z.string() }),
      description: "A card container",
    },
    Metric: {
      props: z.object({
        label: z.string(),
        value: z.string(),
        format: z.enum(["currency", "percent", "number"]).nullable(),
      }),
      description: "Display a metric value",
    },
  },
});

Each component entry carries a Zod schema for its props and a plain-text description. The description is sent to the AI model as part of the prompt so the model understands what each component does and when to use it. The Zod schema enforces the structure of the AI's output at parse time.

The spec format is flat: a root key pointing to the first element, and an elements map where each element has a type (matching a catalog component name), a props object, and a children array of other element keys. This flat structure is intentional for streaming: the renderer can display partial results as the model emits JSON rather than waiting for the full document.

Installing json-render and Rendering AI-Generated Specs

The README shows installation commands for each renderer target. For a React application:

npm install @json-render/core @json-render/react

For React with the included shadcn/ui components (36 pre-built components based on Radix UI and Tailwind CSS):

npm install @json-render/shadcn

For React Native:

npm install @json-render/core @json-render/react-native

Once installed, the registry connects the catalog to actual React components using defineRegistry:

import { defineRegistry, Renderer } from "@json-render/react";

const { registry } = defineRegistry(catalog, {
  components: {
    Card: ({ props, children }) => (
      <div className="card">
        <h3>{props.title}</h3>
        {children}
      </div>
    ),
    Button: ({ props, emit }) => (
      <button onClick={() => emit("press")}>{props.label}</button>
    ),
  },
});

The Renderer component then takes a spec (the AI's JSON output) and the registry, and produces the UI:

function Dashboard({ spec }) {
  return <Renderer spec={spec} registry={registry} />;
}

This three-step sequence, catalog definition then registry implementation then Renderer, is the complete integration path for React. The Renderer handles the mapping from the flat spec structure to the component tree.

The Package Ecosystem Across Renderers

json-render is organized as a monorepo using pnpm workspaces and Turborepo, as shown in the repository's package.json and turbo.json files. Each renderer is a separate npm package under the @json-render scope. The README's package table lists 28 packages, ranging from framework renderers (@json-render/react, @json-render/vue, @json-render/svelte, @json-render/solid) to specialized output targets (@json-render/react-native for mobile, @json-render/remotion for video, @json-render/react-pdf for PDF documents, @json-render/react-email for HTML email, @json-render/ink for terminal UIs, @json-render/image for SVG/PNG output via Satori).

State management is handled through adapters: @json-render/redux, @json-render/zustand, @json-render/jotai, and @json-render/xstate each connect the corresponding state library to json-render's StateStore abstraction. Devtools packages provide a framework-agnostic panel UI with adapters for React, Vue, Svelte, and Solid.

The @json-render/mcp package integrates with MCP Apps, targeting Claude, ChatGPT, Cursor, and VS Code as listed in the README. The @json-render/next and @json-render/tanstack-start packages extend the framework to full-stack rendering with routing, layouts, and SSR.

The monorepo's package.json shows the workspace uses Vitest for testing, Prettier for formatting, and Husky for git hooks. The ci:publish script builds all packages and publishes them to npm with provenance attestation.

Where json-render Is the Wrong Tool

json-render requires an AI model at runtime to generate the specs. A static application whose UI does not change based on natural language input has no use for the framework. The JSON spec generation step presupposes a model call, which adds latency, token cost, and a network dependency that a conventional component-based UI does not have.

The catalog design is a design-time decision that constrains what the AI can express. If the catalog is too small, the AI will not be able to generate useful interfaces; if it is too large, the model may use components inconsistently or combine them in unintended ways. Getting the catalog right for a specific application requires iteration, and the README does not document how to measure whether a catalog is well-suited to the model being used.

The @json-render/shadcn package provides 36 pre-built shadcn/ui components based on Radix UI and Tailwind CSS. Teams not using Tailwind or those with an existing component system cannot use the shadcn package directly; they must implement their own registry bindings for whatever components they have. The pre-built components are a starting point for projects without an existing design system, not a universal kit.

Video conversion support in the framework context is separate from file I/O: the @json-render/remotion package targets Remotion's video rendering pipeline, not general video file handling.

json-render Compared to Direct JSX Generation

The obvious alternative to json-render is having an AI model generate JSX or HTML directly, then rendering it. The practical problem with this approach is that an AI generating arbitrary JSX can produce invalid markup, reference components that do not exist, inject event handlers with unexpected behavior, or output code that fails to parse. Sanitizing and validating arbitrary AI-generated JSX before rendering is a significant and ongoing engineering problem.

json-render's position is that constraining the model's output to a JSON schema derived from a fixed catalog eliminates this class of problem. The model cannot reference a component outside the catalog; if it tries, the spec fails schema validation before the renderer sees it. The trade-off is that the expressiveness of the interface is bounded by the catalog: anything the developer did not define as a component cannot appear in the output.

This is a clear trade-off, not a flaw. Applications that need a truly open-ended AI-generated interface, where the model can produce any structure or interaction, will hit the catalog ceiling. Applications that need predictable, brand-consistent, accessible interfaces generated from natural language input are the use case json-render is built for.

Version History and Project Status

The most recent release is v0.21.0, published on 2026-09-18. Before that, v0.20.0 was published on 2026-08-18 and v0.19.0 on 2026-05-12. The release cadence shows roughly monthly minor versions in the recent period. The last push to the main branch was on 2026-09-25. The repository is not archived.

The package.json scripts include version:sync and version:check, which synchronize and validate version numbers across the monorepo's packages. The ci:publish script publishes all packages simultaneously with provenance attestation and public npm access. The repository uses pnpm workspaces, so installing the development dependencies requires pnpm and the portless tool (referenced in the predev script check).

The project is licensed under Apache-2.0. As a Vercel Labs project, it operates under the labs designation, which the README links to as vercel.com/labs. Labs projects from Vercel are experimental products under active development; the version numbering starting from 0.x reflects that the API has not yet been declared stable.

Editorial conclusion

json-render suits teams that want to let an AI model produce a user interface at runtime without giving the model free rein over the DOM. If the application's UI must adapt to a user's prompt or context while remaining bounded to a known set of components and actions, the catalog and registry model is a direct fit. Teams building static interfaces or those whose UI never needs to change based on natural language input have no need for the framework's machinery. Before adopting it, verify the target renderer package exists in the npm package listing for your framework (React, Vue, Svelte, Solid, React Native, and others are listed), and confirm whether your AI provider's output can be streamed as a SpecStream, since the README describes progressive rendering as part of the framework's design.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes