Generate Zod Validation Schemas for Next.js Server Actions

Generate the skeleton, coerce FormData-string fields, then safeParse before the DB write.

Sample parsed payload:
{ "title": "Hello", "price": 9.99, "published": true }

Generated:
import { z } from "zod";
export const createPostSchema = z.object({
  title: z.string(),
  price: z.number(),
  published: z.boolean()
});

Action (you add coercion):
'use server';
export async function createPost(_: unknown, formData: FormData) {
  const r = createPostSchema.extend({
    price: z.coerce.number(),
    published: z.coerce.boolean()
  }).safeParse(Object.fromEntries(formData));
  if (!r.success) return { errors: r.error.flatten().fieldErrors };
  await db.post.create({ data: r.data });
  return { ok: true };
}

The generated z.infer type names the action's input; the flattened fieldErrors map straight onto your form's error display.

export type CreatePostSchema = z.infer<typeof createPostSchema>;

'use client';
const [state, action] = useActionState(createPost, { errors: {} });
<form action={action}>
  <input name="title" />
  {state.errors?.title?.[0]}
  <input name="price" />
  {state.errors?.price?.[0]}
</form>

If you build a nested object before parsing (e.g. grouping address fields), the schema mirrors it.

Sample:
{ "name": "Sam", "address": { "city": "NYC", "zip": "10001" } }

Generated:
export const schema = z.object({
  name: z.string(),
  address: z.object({
    city: z.string(),
    zip: z.string()
  })
});
// Note: FormData is flat — you must assemble the nested
// object yourself before parsing.

Turn on Strict objects so an extra hidden field or stale input can't slip into the mutation payload.

Strict objects: ON

export const schema = z.strictObject({
  title: z.string(),
  published: z.boolean()
});

safeParse({ title, published, _csrf })
// → success: false, 'Unrecognized key(s): _csrf'
// The DB write never receives _csrf.

Unchecked checkboxes are simply absent from FormData, and checked ones send 'on'. The generated z.boolean() won't handle either — preprocess it.

Generated:
active: z.boolean()

Reality: formData has no 'active' key when unchecked,
and 'on' when checked. Replace with:
active: z.preprocess(v => v === 'on' || v === 'true' || v === true,
                     z.boolean())
// now absent → false, 'on' → true

A sample { price: 9.99 } infers z.number(), but formData.get('price') is '9.99', so safeParse(Object.fromEntries(formData)) fails with 'Expected number, received string'. Switch those fields to z.coerce.number(). This is the single most common Server Action validation bug.

HTML checkboxes send 'on' when checked and nothing at all when unchecked. A generated z.boolean() fails both ways. Use z.preprocess(v => v === 'on', z.boolean()) or .optional().transform(Boolean) so absence becomes false.

Inference reads runtime types, so emails, URLs, and dates are z.string(). Add .email(), .url(), or .datetime() after generating. The structural skeleton is intentionally constraint-free.

If your sample is nested (address.city) but you parse raw FormData, the keys are flat ('address.city' or 'city'). Either assemble the nested object before parsing, or flatten the schema. The generator mirrors the sample you give it, not the wire format.

A null value yields z.null(), accepting only null. For a column that is sometimes a value, rewrite to z.string().nullable(). FormData never produces actual null, so reconsider whether the field should be .optional() instead.

A <select multiple> or repeated input produces multiple FormData entries; Object.fromEntries keeps only the last. Use formData.getAll('key') to get the array, and model it as z.array(z.string()). A single-value sample will infer the wrong type here.

With Strict on, z.strictObject rejects keys you didn't declare — including framework or CSRF hidden inputs you forgot to add. This is the intended safety behaviour; either add those keys to the schema or strip them before parsing.

If you paste an array of payloads larger than your tier's row cap (100 on free, 1,000 on Pro), it is sliced to the first N before inference. For a single action's shape, paste one representative object — extra rows don't enrich the schema.