The validation & schema layer for React forms in 2026: Zod 4, Valibot, ArkType — and why Standard Schema changed the question

Decision. Default to Zod 4 — it is the only one of the four whose ecosystem (drizzle-zod, tRPC, Next.js docs, AI SDKs) covers the whole shared-schema path from DB row to form field [17] [19]. Reach for Valibot only when the schema is client-bundled and the kilobytes are load-bearing (1.37 kB vs 17.7 kB for a login form) [8]. Reach for ArkType when you validate at high volume or want TS-syntax schemas (~4× Zod v4 throughput) [20]. Yup/Joi are maintenance-mode choices — both now speak Standard Schema, so keep them if you have them, don’t start with them [21] ⭐ 23.7k [22] ⭐ 21.2k. The 2026 twist: because Standard Schema v1 is now near-universal, picking wrong is cheap at the form-library boundary and expensive at the shared-schema boundary.

Current versions (July 2026)

Zod out-downloads React itself (~224M vs ~153M weekly) [24] — mostly transitive, but it is the datapoint that explains every ecosystem gap below.

What Standard Schema actually standardises (and what it does not)

Standard Schema is ~60 lines of TypeScript interfaces, co-authored by the Zod, Valibot and ArkType maintainers [1]. A schema exposes a ~standard property; a consumer calls schema["~standard"].validate(input) and gets { value } or { issues } [16]. No adapter, no peer dependency, no typeschema-style shim.

Two things fall out that matter for forms:

1. Issue is deliberately thin. The spec’s issue type is { message: string; path?: ... } — no error code, no params [2] ⭐ 3.6k. → a Standard-Schema-consuming form library cannot translate or re-word your errors; i18n must happen inside the schema library. This is the single most under-discussed consequence of the spec.

2. Spec v1.1 (Dec 2025) added StandardJSONSchemaV1 [3] — a standardised ~standard.jsonSchema.input()/.output() converter. Joi 18 already ships it [22] ⭐ 21.2k; it is what will eventually let one schema drive OpenAPI, LLM tool-calling and form generation without vendor-specific toJSONSchema calls.

The comparison

Ecosystem: who accepts what

The honest summary: at the form-library boundary the choice is free; at the ORM / RPC / codegen boundary it is not. The practitioner post that best captures 2026 reality migrated two forms to Valibot for ~18 kB gzip and ~140 ms LCP, then stopped — because drizzle-valibot lagged drizzle-zod on a nullable JSONB column, and the schema was shared with the DB [19].

Strings in, typed data out

Every <input> yields a string. Every schema library therefore has an input type ≠ output type problem, and this is where most 2026 form bugs live.

Zod. z.coerce.number() is the obvious move and the wrong one for forms: its input type is unknown [6], which erases the compile-time contract with the form state. Prefer z.string().transform(Number).pipe(z.number()) or z.preprocess. Then wire the three-generic form:

const schema = z.object({ age: z.coerce.number().min(18) });
// RHF holds z.input, hands you z.output in onSubmit
useForm<z.input<typeof schema>, unknown, z.output<typeof schema>>({
  resolver: standardSchemaResolver(schema),
});

Resolvers v5 infers both sides from the schema, so the explicit generics are only needed when you wrap useForm yourself [32] [6]. For checkboxes/env-ish strings, z.stringbool() beats hand-rolled preprocessors [6].

Valibot. Explicit by construction: v.pipe(v.string(), v.toNumber(), v.minValue(18)), with InferInput = string and InferOutput = number [9] [29]. Verbose, but the input/output split is impossible to get wrong.

ArkType. Morphs: type("string.numeric.parse"). The filter/narrow distinction (validate before vs after the morph) is the cleanest model of the three — a filter rejects a 10 MB string before you parse it, a narrow checks the resulting number [12].

⚠ TanStack Form does not hand back transformed values from validators [15] — the schema validates, but you re-parse in onSubmit if you want the coerced output. Budget for that.

⚠ Conform inverts this: parseWithZod introspects the schema and injects the coercion + empty-string stripping for you, so a plain z.number() works against raw FormData [18]. It is the only one of the three that makes FormData a first-class input.

One schema, two runtimes

The pattern that matters: define once, validate on the field and in the Server Action.

// schema.ts — no 'use server', no 'use client'
export const signup = z.object({
  email: z.email(),
  age: z.coerce.number().min(18),
});

// action.ts
'use server';
export async function signupAction(_prev: State, fd: FormData) {
  const r = signup.safeParse(Object.fromEntries(fd));
  if (!r.success) return { errors: z.flattenError(r.error).fieldErrors };
  // r.data is typed z.output<typeof signup>
}

z.flattenError() / z.treeifyError() replace v3’s .flatten() / .format(); flattenError yields { formErrors, fieldErrors } — exactly the shape useActionState wants to hand back to the client [33].

How each library handles the split:

• Zod — one file, imported by both. Server-only refinements (uniqueness checks) go in a .superRefine() on a serverSignup = signup.superRefine(...) extension; the client imports the base. ⚠ The whole schema module lands in the client bundle, so keep DB imports out of it.
• Valibot — same shape, but its tree-shakeability means the client only pays for the actions it actually references [8]. Best-in-class here if your server side does not depend on the Zod-only ecosystem [19].
• ArkType — works, but the ~20 kB runtime lands in the client bundle regardless of schema size [20]; a poor trade unless the same schemas are also doing high-volume server validation.
• Yup/Joi — Joi is Node-oriented and cannot infer values from a schema [14] ⭐ 2.3k, which breaks the “typed data out” half of the contract. Use for server-only validation you already own.
• next-safe-action / Conform — remove the boilerplate above entirely and are library-agnostic (next-safe-action via Standard Schema [16], Conform via parseWithZod/parseWithValibot [18]).

The one-schema pattern is what pins your choice. Standard Schema makes the form library indifferent; it does nothing to make drizzle-zod, zod-openapi or the AI SDK’s tool schemas indifferent. Pick the library that survives contact with your server stack, then live with its bundle on the client — or split deliberately (Valibot client / Zod server) and accept translating at the boundary.

Recommendation

1. New app, shared client+server schemas → Zod 4. The v4 rewrite closed the two historical objections (6.5–14.7× runtime, 10× less tsc thrash on .extend() chains, half the bundle) [4], it has 40+ locales built in [5], and everything downstream of your form — ORM, RPC, OpenAPI, LLM tools — assumes it.
2. Bundle-critical, client-only schemas (edge, mobile web, embeddable widget) → Valibot. 1.37 kB vs 17.7 kB is not a rounding error [8], and it pairs cleanly with Conform and TanStack Form. Use zod/mini [7] instead only if you refuse a second library — its DX is worse than Valibot’s for the same win.
3. High-throughput validation or TS-native schema syntax → ArkType. ~4× Zod v4 [20]. ⚠ Budget for compile-time cost on large schemas and for rolling your own i18n [13].
4. Yup / Joi → don’t start here. Both now implement Standard Schema [21] ⭐ 23.7k [22] ⭐ 21.2k, which means an existing Yup/Joi codebase can adopt TanStack Form or next-safe-action without rewriting schemas. That is a migration lifeline, not a reason to pick them.
5. Whatever you pick, do i18n inside the schema library. The Standard Schema Issue carries only message + path [2] ⭐ 3.6k — a form library downstream of the spec has nothing left to translate with.