json-render is a generative UI framework from Vercel Labs that lets a language model assemble interfaces out of components you define in advance, instead of letting it invent markup of its own. It is aimed at developers shipping AI-generated screens — agent interfaces, dynamic dashboards, personalized views — into real products, where an improvised layout is a defect rather than a demo. The project is written in TypeScript, published under Apache-2.0, and has gathered about 17,600 stars and 928 forks since it first appeared in January 2026.
What it does
The problem it targets is simple to state: ask an AI to build your UI and it improvises everything, differently every time. That is tolerable in a prototype and alarming once the model's output is a screen a customer actually sees.
json-render inverts the arrangement. You declare the components and actions the model is allowed to use, and the model's only job is to choose among them and arrange them. The README describes this as predefined components and actions for safe, predictable output, and as a way to generate dynamic, personalized UIs from prompts without sacrificing reliability.
In practice that buys three things the channel's write-up highlights:
- The model designs layout and composition, while you keep control over what is allowed to render at all.
- You define a schema and the model's response conforms to it, so you are handling structured data rather than parsing unpredictable UI output.
- One component catalog can be rendered by several different targets rather than being rewritten per platform.
How it works
The project is split into a core package and a set of renderers. @json-render/core is the piece you always install — it holds the catalog and the schema side of things. On top of it you add whichever renderer matches where the interface has to appear.
The install instructions in the README show how wide that list is:
@json-render/reactfor React, or@json-render/shadcnfor React with pre-built shadcn/ui components@json-render/react-nativefor mobile@json-render/vue,@json-render/svelteand@json-render/solidfor the other major frameworks@json-render/remotionfor video and@json-render/react-pdffor PDF documents@json-render/react-email, together with@react-email/componentsand@react-email/render, for HTML email@json-render/inkfor terminal UIs- a Next.js package for full applications, covering routes, layouts, server-side rendering and metadata
The common thread is that the model never emits framework code. It emits a description that matches your schema, and the renderer for the target platform turns that description into the real thing. Because actions are part of what you declare, interactivity is constrained the same way the visual components are.
Getting started
Installation is a single npm line per target. For a React app with the bundled shadcn/ui components, npm install @json-render/shadcn is enough to start; for a plain React setup it is npm install @json-render/core @json-render/react, and the other targets follow the same core-plus-renderer pattern. From there the work is defining your catalog: which components exist, what props they take, and what actions the model may trigger.
Since the repository is the primary reference, and it has been actively pushed to as recently as September 2026, it is worth reading the current docs in the repo before wiring anything into a production path — the package list above is what the README states, and the specifics of catalog and schema authoring live in the project's own documentation rather than in this summary.
When to use it / when not
This is a good fit when a model is genuinely part of the rendering loop: an assistant that has to show a form, a chart or a summary card; a dashboard that reshapes itself per user; an agent whose steps need a visible surface. It is also a strong fit when the same generated interface must land in more than one place — a React app and a React Native app, or a screen and a PDF of that screen.
It is the wrong tool when there is no model involved at all. If your screens are static, a component library and ordinary routing are less machinery for the same result. It also deliberately refuses the thing some people want from generative UI: the model cannot go beyond your catalog and compose something you never anticipated. That constraint is the entire point, but it is a constraint. And the whole stack is JavaScript and TypeScript, so a Python or Go backend would need a JS rendering layer to use it.
If you are building anything where an AI decides what the user sees, json-render deserves a serious look. It comes from Vercel Labs, carries a permissive license, and answers the one question that stops most teams from shipping generative interfaces — how do you let a model design a screen without letting it invent one. Teams whose AI features are still stuck at "text in a chat bubble" because richer output felt too unpredictable are exactly the audience here.