Zod vs Yup vs Valibot: Schema Validation 2026

TL;DR

Zod is the default choice for TypeScript projects in 2026 — 31M weekly downloads, excellent DX, and Zod v4 closed most of the performance gap. Valibot wins on bundle size (1.4 KB vs Zod's 15+ KB) and is the right pick for edge/bundle-sensitive apps. Yup remains relevant for Formik codebases but has lost significant ground to both competitors.

Key Takeaways

• Zod: 31M weekly downloads, 38.5K GitHub stars — the clear ecosystem leader
• Yup: 5.1M weekly downloads, 23.6K GitHub stars — strong but declining market share
• Valibot: 1.4M weekly downloads, 7.7K GitHub stars — fastest growing, bundle-first design
• Zod v4 is 14x faster at string parsing, 7x faster at arrays vs Zod v3
• Valibot's bundle footprint is ~1.4 KB for a login form vs Zod v4's 15 KB
• All three support Standard Schema — framework-level interoperability is now guaranteed
• Yup has no TypeScript-first design — type inference is bolted on, not native

---

Why Schema Validation Matters in 2026

Runtime schema validation is no longer optional. With tRPC, server actions, and form libraries all converging on schema-driven APIs, your choice of validation library now affects your entire stack — bundle size, TypeScript inference quality, and integration with tools like React Hook Form, Hono, and Valibot.

The landscape shifted dramatically in 2025 with two events: Zod v4's release (massive performance leap) and the Standard Schema specification reaching v1.0. Standard Schema means Zod, Valibot, and ArkType can now be used interchangeably in compatible frameworks — your schema library is less locked-in than ever.

Before Standard Schema, choosing a validation library was a sticky decision. If you picked Zod for a React Hook Form project, switching later meant rewriting every schema. If a library added Zod support but not Valibot support, you were locked in by your initial choice. Standard Schema changes this by defining a common interface that framework authors can target once and get compatibility with all compliant libraries. React Hook Form, Hono's validator middleware, and several others have adopted Standard Schema, which means the ecosystem pressure that used to favor only Zod now distributes across compliant libraries.

The practical stakes of schema validation extend beyond form inputs. API route handlers validate request bodies. tRPC procedures declare input schemas that generate both TypeScript types and runtime checks. Drizzle's insert operations can be validated against derived schemas. Server actions in Next.js and Remix parse FormData through schema declarations. Every one of these integration points is affected by your choice of schema library — which is why 2026 is a genuinely interesting time to compare the field.

For a deeper look at the form validation ecosystem, see Best React Form Libraries 2026 and Zod v4 vs ArkType vs TypeBox vs Valibot.

---

Comparison Table

Dimension	Zod v4	Yup 1.x	Valibot 1.x
Weekly Downloads	31M	5.1M	1.4M
GitHub Stars	38.5K	23.6K	7.7K
Bundle Size (login form)	~15 KB	~24 KB	~1.4 KB
TypeScript-first	Yes	Partial	Yes
Standard Schema	Yes	No	Yes
Async validation	Yes	Yes	Yes
Tree-shakable	Partial (Mini)	No	Yes
Inference quality	Excellent	Good	Excellent
Learning curve	Low	Low	Medium

---

Zod v4

Zod, created by Colin McDonnell, has been the TypeScript validation standard since 2020. The v4 release in 2025 was a landmark: 14x faster string parsing, 7x faster array parsing, 6.5x faster object parsing compared to v3. Zod v4 also introduced Zod Mini — a tree-shakable, functional variant that brings bundle size down from ~68 KB (v3 CommonJS) to around 15 KB.

import { z } from "zod";

const UserSchema = z.object({
  name: z.string().min(2).max(50),
  email: z.string().email(),
  age: z.number().int().min(0).max(120).optional(),
  role: z.enum(["admin", "user", "guest"]),
});

type User = z.infer<typeof UserSchema>;

// Parse (throws on failure)
const user = UserSchema.parse({ name: "Alice", email: "alice@example.com", role: "admin" });

// Safe parse (returns result object)
const result = UserSchema.safeParse(rawInput);
if (result.success) {
  console.log(result.data);
} else {
  console.error(result.error.flatten());
}

Zod Mini uses the functional pipe style for better tree-shaking:

import { z, pipe, string, email, object, parse } from "zod/mini";

const EmailSchema = pipe(string(), email());
parse(EmailSchema, "user@example.com"); // "user@example.com"

Zod's biggest strength is its ecosystem depth. React Hook Form, tRPC, Drizzle, Hono, Next.js server actions — virtually every major TypeScript tool has first-class Zod support. When you reach for a new library and ask "does it have a Zod adapter?", the answer is almost always yes. This network effect compounds over time: the more tools support Zod natively, the more friction there is in switching away, and the more new tools prioritize Zod support first.

Zod v4's performance improvements are substantial and worth understanding in detail. The team rewrote the core parsing engine and achieved 14x faster string parsing, 7x faster array parsing, and 6.5x faster object parsing compared to v3. For most applications, raw parsing performance at the library level isn't the bottleneck — network latency and database queries dominate. But for high-throughput API servers processing thousands of requests per second, these improvements translate directly to server capacity. The v4 improvements also matter for the cold start cost in edge functions, where parsing overhead is more visible.

Error formatting is another area where Zod excels. The flatten() method produces nested error objects that map directly to form field paths, making it trivial to display field-level validation errors in a UI. The .format() method gives you the full error tree with custom message support. This level of ergonomic error handling is one of the reasons Zod became the default for form-adjacent validation.

When Zod is the right choice:

• General TypeScript projects where ecosystem compatibility matters
• tRPC or server actions with complex schemas
• Team familiarity is a priority
• You need rich error formatting out of the box
• Existing codebase with Zod already present

---

Yup

Yup was the original JavaScript schema validation library and reached dominance through its Formik integration. Its fluent, chainable API was intuitive for JavaScript developers who weren't yet thinking TypeScript-first.

import * as yup from "yup";

const UserSchema = yup.object({
  name: yup.string().min(2).max(50).required(),
  email: yup.string().email().required(),
  age: yup.number().integer().min(0).max(120),
  role: yup.mixed<"admin" | "user" | "guest">().oneOf(["admin", "user", "guest"]).required(),
});

type User = yup.InferType<typeof UserSchema>;

try {
  const user = await UserSchema.validate({ name: "Alice", email: "alice@example.com", role: "admin" });
} catch (err) {
  if (err instanceof yup.ValidationError) {
    console.error(err.errors);
  }
}

Yup's asynchronous validation is genuinely useful — you can validate against a database or API within your schema:

const UsernameSchema = yup.string().test(
  "unique-username",
  "Username already taken",
  async (value) => {
    const exists = await checkUsernameExists(value);
    return !exists;
  }
);

Where Yup struggles in 2026: TypeScript inference is retrofitted rather than native. InferType works but edge cases (discriminated unions, recursive schemas) produce less precise types than Zod. Yup also has no Standard Schema support, meaning newer frameworks won't add first-class Yup adapters going forward. The library has essentially reached feature stability — active maintenance continues, but the project isn't innovating at the pace of Zod or Valibot.

Yup's bundle size is also its largest practical disadvantage. At ~24 KB for a simple login form, it's the heaviest of the three. Unlike Zod Mini or Valibot, Yup offers no tree-shakable variant. Every validator, whether you use it or not, ships in the bundle. For server-side validation this doesn't matter, but for client-side or edge validation it's a meaningful cost.

That said, Yup's async-first design is genuinely useful in certain contexts. When validation logic needs to consult external state — checking username uniqueness against a database, verifying an email isn't blocklisted, confirming a promo code is valid — Yup's .test() method makes this clean and composable in a way that feels natural to JavaScript developers. Zod supports async refinements too, but Yup's API for it feels more intuitive to developers who grew up with promise-based JavaScript.

When Yup is the right choice:

• Existing Formik codebases already using Yup
• Teams with strong JavaScript (not TypeScript) background
• Complex async validations are the dominant use case
• Migrating incrementally from Joi with minimal disruption

---

Valibot

Valibot takes a fundamentally different architectural approach: every validator is a pure function, and schemas are composed via a functional pipe() API. This design enables aggressive tree-shaking — unused validators simply aren't bundled.

import * as v from "valibot";

const UserSchema = v.object({
  name: v.pipe(v.string(), v.minLength(2), v.maxLength(50)),
  email: v.pipe(v.string(), v.email()),
  age: v.optional(v.pipe(v.number(), v.integer(), v.minValue(0), v.maxValue(120))),
  role: v.picklist(["admin", "user", "guest"]),
});

type User = v.InferOutput<typeof UserSchema>;

// Safe parse
const result = v.safeParse(UserSchema, rawInput);
if (result.success) {
  console.log(result.output);
} else {
  console.error(v.flatten(result.issues));
}

Bundle size in practice: A login form schema (email + password) compiles to ~1.4 KB with Valibot vs ~15 KB with Zod v4 and ~24 KB with Yup. For edge functions, Cloudflare Workers, or mobile web apps, this difference is material. Cloudflare Workers has a 1 MB compressed bundle limit. If your worker handles form validation, Valibot takes 1.4 KB of that budget vs Zod's 15 KB. For a simple worker this doesn't matter, but for workers that also bundle a route framework, database client, and business logic, every kilobyte counts. Valibot's architecture was specifically designed with this constraint in mind — the library author originally built it while working on an edge-deployed application and found Zod's bundle cost unacceptable.

// Valibot v1 — Standard Schema compatible
import { toJsonSchema } from "@valibot/to-json-schema";

const LoginSchema = v.object({
  email: v.pipe(v.string(), v.email()),
  password: v.pipe(v.string(), v.minLength(8)),
});

// Generate JSON Schema for OpenAPI
const jsonSchema = toJsonSchema(LoginSchema);

Valibot's runtime performance is roughly 2x faster than Zod v3 and comparable to Zod v4. The modular API requires slightly more verbose code for complex schemas, which is the primary DX tradeoff. Where Zod lets you write z.string().email().min(5) as a method chain, Valibot requires v.pipe(v.string(), v.email(), v.minLength(5)). This is more characters but also more explicit — each validator is a discrete, nameable function, which is better for static analysis and tree-shaking.

The Valibot ecosystem has grown substantially in 2025-2026. React Hook Form's Valibot resolver is production-ready. Hono's validator middleware supports Valibot natively. The @valibot/to-json-schema package generates OpenAPI-compatible JSON Schema from Valibot schemas, which matters for tightly-coupled API documentation. Standard Schema compliance means any library that added Standard Schema support automatically works with Valibot without additional adapter code.

One important consideration: Valibot's error messages are less detailed by default than Zod's. Zod generates rich, human-readable error messages with path information and issue codes out of the box. Valibot's issues are more raw and require manual formatting to display nicely in a UI. This is a deliberate tradeoff — better tree-shaking requires smaller default outputs — but it means more work for form validation UI code.

When Valibot is the right choice:

• Edge functions, Cloudflare Workers, or bundle-size-critical apps
• New projects that want maximum tree-shaking from day one
• You want Standard Schema compliance without Zod's weight
• React Native or embedded web contexts where bundle size is measured in KB

---

When to Choose Each

Choose Zod v4 when you need the richest ecosystem, best-in-class DX, and are building general TypeScript apps. The gap with Valibot on performance and bundle size is now smaller than ever, and the ecosystem advantage is enormous. Zod is particularly strong for tRPC projects — the library was designed with tRPC in mind, and the integration is seamless in both directions.

Choose Yup only if you're maintaining an existing Formik codebase or migrating from Joi. For new projects, Zod or Valibot are better starting points. The maintenance burden of keeping Yup in a new project when better alternatives exist isn't justified by any significant advantage.

Choose Valibot when bundle size directly impacts user experience — edge functions, mobile-optimized web apps, or any context where 15 KB matters. Valibot's growing ecosystem (React Hook Form resolver, Hono validator, Standard Schema support) means you won't sacrifice compatibility for the bundle savings.

A note on migration cost: All three libraries have similar API surface areas for simple schemas. Migration from Yup to Zod is well-documented and usually straightforward. Migration from Zod to Valibot requires rewriting schemas (different API), but codegens and scripts are available. If you're on Zod and bundle size becomes a concern, consider Zod Mini before switching to Valibot — the functional API is closer to Valibot's style and might be sufficient.

For related comparison, see Valibot vs Zod v4 and Joi vs Zod 2026.

---

Methodology

Data sourced from npm trends (March 2026), GitHub repository pages, and official benchmarks from the Valibot documentation and Zod v4 release notes. Bundle sizes measured with esbuild for a login form schema (email + password fields). Download counts represent weekly averages from the 30 days prior to publication.