AutoForm: render React forms from your existing Zod, Yup or Joi schema

The boilerplate AutoForm removes from schema-backed forms

If you already define a Zod schema for an API, you have a description of every field, its type and its constraints. What you do not have is a form. Turning that schema into a working React form means picking an input component per field type, wiring each one to a form library, connecting validation, and repeating the process every time the schema changes. AutoForm exists to remove that repetition. The README frames it as a drop-in form builder for internal tools and simple forms with existing schemas, and gives the admin panel case directly: pass the schema and you are done. The intended audience is a developer who already has schemas for an API and wants a quick editing surface, not a designer building a public-facing checkout flow. That scope matters, because the same README states AutoForm does not aim to be a full-featured form builder or to support every edge case in your schema.

How the schema provider and renderer split the work

AutoForm is built around three separable concerns: the schema, the rendering, and the UI library. The schema side is wrapped in a provider. The README's example imports ZodProvider from @autoform/zod and constructs it from a plain Zod object, exporting the result as schemaProvider. The React side imports AutoForm from a package path that names both the UI library and the form library, for example @autoform/mui/react-hook-form. That import path is the architecture in miniature: the same schema provider can be paired with a different UI package or a different form library without rewriting the schema. The component receives the provider through the schema prop, an onSubmit callback, and a withSubmit boolean that renders a submit control. The README states that AutoForm maps schema fields to the right input components, connects them to the form library, and sets up validation. It also states that it does not change how you write custom inputs or access data, state and methods: you keep using your form library as usual. Customization runs through a fieldConfig option, and the README points to customizing the renderer in your own project as the deeper escape hatch.

Installing AutoForm and rendering your first form

The README does not give a single install command for the React packages. It directs readers to the getting-started guide for their form library, with separate guides for React Hook Form and TanStack Form, and the documentation site carries the API references. What the README does show is the shadcn CLI path, in a comment inside the React example: the component is installed as "@/components/ui/autoform/react-hook-form". For anyone not on shadcn, the package import is the entry point, and the package name encodes both the UI library and the form library.

The first step is a schema provider. The README's example builds one from a Zod object with a string, a coerced date and an email field, and exports it:

import { z } from "zod";
import { ZodProvider } from "@autoform/zod";

const userSchema = z.object({
  name: z.string(),
  birthday: z.coerce.date(),
  email: z.string().email(),
});

export const schemaProvider = new ZodProvider(userSchema);

The second step is the form itself. Note the import path: it names Material UI and React Hook Form, so a project on a different UI library would import the matching package instead. The onSubmit callback receives the parsed data, and withSubmit adds the submit control:

import { AutoForm } from "@autoform/mui/react-hook-form";
// shadcn CLI install: "@/components/ui/autoform/react-hook-form"
import { schemaProvider } from "./schema";

function MyForm() {
  return (
    <AutoForm
      schema={schemaProvider}
      onSubmit={(data) => {
        console.log(data);
      }}
      withSubmit
    />
  );
}

What you should see is a form with one input per schema field, validated against the schema you already wrote. The README does not document what the submit control is labelled or how errors are displayed, so check those against your UI package before shipping the form to users.

Where AutoForm stops: edge cases, complex forms and the wrong fit

The most useful sentence in the README is a limitation: AutoForm does not aim to be a full-featured form builder or support every edge case in your schema. Read that as the boundary of the tool. Forms grow conditionally: a field appears only when another field has a particular value, or a section is skipped entirely. The README's answer to that class of problem is customization, listing fieldConfig for how fields render and renderer customization for anything deeper. Neither is a schema-level conditional system, and the README does not describe one. If your form is the product, with multi-step flows, branching and bespoke interaction, generated fields will fight you. The README itself points outward for that case, citing AutoForm YAML as an example of extending the approach into more powerful, YAML-based, multi-page forms. A second boundary is schema shape. The mapping from schema field to input component is the core of the tool, so a field type the renderer does not recognize is where you fall back to custom work. The README does not enumerate which types are supported, so that is something to confirm against the documentation for your schema library.

AutoForm and the original shadcn/ui component it grew out of

The natural comparison is the project AutoForm evolved from: the shadcn/ui component at vantezzen/auto-form. The README says AutoForm evolved from that component into a standalone library with broader UI and schema support, and the repository still carries a registry.json at the top level for the shadcn registry. The difference in approach is the axis of reuse. The original was a component you copied into your project and adapted in place, which is how shadcn distributes everything. AutoForm is a published library with separate packages per UI library and per validation library, so the schema provider and the renderer are versioned and upgraded independently of your application code. That is the trade: you stop owning the rendering code, and you start depending on package releases and their upgrade cadence. If your schema is Zod and your UI is shadcn, the older component may still be the smaller dependency. If you need Yup or Joi, or Mantine, Ant Design or Chakra UI, the standalone library is the one that covers you.

Maintenance, releases and the MIT licence across the monorepo

The repository is a TurboRepo monorepo, with apps/ and packages/ directories, a pnpm workspace, and turbo.json driving the build. The last push was on 2026-07-15, and the repository is not archived. The root package.json sets engines to node >=18 and pnpm >=9.0.0, and pins packageManager to [email protected], so contributors need a matching toolchain. The documented contributor loop is pnpm install followed by pnpm dev, which the README says starts the development server for the documentation website and the AutoForm package. Release checks are pnpm build, pnpm check:packages and pnpm cypress, with pnpm cypress:open for the Cypress UI. Changes are documented with pnpm changeset, and releases are cut with pnpm changeset version and pnpm changeset publish. The README states that all packages in the monorepo are licensed under MIT, and the root package.json carries the same licence field. That is permissive for commercial use, but it is not legal advice: check the licence of each individual package you install and the terms of the UI libraries AutoForm renders into, since those are separate projects with their own licences.

Editorial conclusion

Adopt AutoForm if you already maintain a Zod, Yup or Joi schema and need a simple admin or internal form without hand-writing field bindings. Do not adopt it if your forms need heavy conditional logic, multi-page flows or a schema shape the renderer does not map cleanly; the README says it does not aim to support every edge case. Before committing, verify that your UI package has an official AutoForm package, check how your date and enum fields render, and confirm whether the fieldConfig escape hatch covers the fields you cannot accept as generated.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. vantezzen/autoform on GitHub