Zod vs Yup: Schema Validation Libraries

Zod and Yup are JavaScript schema validation libraries that let you define data shapes and validate runtime values against those shapes. Both are widely used for form validation, API input validation, and configuration parsing. The choice between them has become one of the most common library decisions in the TypeScript ecosystem.

Yup launched in 2016 and became the dominant validation library largely through its integration with Formik, the popular React form library. It provides a chainable API for defining schemas and validation rules. Yup was designed before TypeScript became ubiquitous in the JavaScript ecosystem, and while it has added TypeScript support, type inference was not part of its original design.

Zod launched in 2020 with TypeScript as a first-class concern. Its core innovation is bidirectional type inference — you define a Zod schema, and TypeScript automatically infers the corresponding type. This eliminates the common problem of maintaining separate type definitions and validation schemas that can drift out of sync. As of 2026, Zod has overtaken Yup in weekly npm downloads, reflecting the JavaScript ecosystem's shift toward TypeScript-first tooling.

Zod's TypeScript integration is its defining feature. When you define a Zod schema, you can extract the TypeScript type using z.infer<typeof schema>. This means your runtime validation and compile-time types are always in sync — change the schema, and the type updates automatically. There is no possibility of the type and validator disagreeing because they derive from the same source of truth.

Yup's TypeScript support is functional but less integrated. You can use InferType<typeof schema> to extract types, but the inference is less precise. Complex schemas with conditional fields, transformations, and nested objects can produce TypeScript types that do not accurately reflect the validated output. In practice, many Yup users define their TypeScript interfaces manually alongside Yup schemas, which defeats the purpose of automatic inference.

For TypeScript projects, this difference is substantial. Zod eliminates an entire category of bugs — the type says one thing, the validator allows another. With Yup, these discrepancies are possible and, in complex schemas, common. If your project uses TypeScript (and most modern projects do), Zod's type inference is a compelling reason to choose it.

Zod's API is functional and composable. Schemas are immutable objects that can be combined, extended, and transformed. The z.object(), z.string(), z.number() pattern is consistent and predictable. Transformations are part of the schema — z.string().transform(val => parseInt(val)) both validates that the input is a string and transforms it to a number, with the output type correctly inferred as number.

Yup's API uses a chainable builder pattern — yup.string().required().min(5).max(100). This is readable and familiar to developers who have used jQuery or similar chainable APIs. Yup's .shape() method for objects and .of() for arrays provide clear schema composition. The API has accumulated some inconsistencies over its longer development history, but it remains intuitive for common use cases.

Zod's API is more consistent and predictable for complex schemas. Discriminated unions, recursive types, and schema composition are all well-supported with clear patterns. Yup handles these cases but with more workarounds and less intuitive syntax. For simple form validation schemas, both APIs are equally productive. For complex data models, Zod's design scales better.

Yup's longest-standing ecosystem advantage was its Formik integration — Formik was the most popular React form library and used Yup as its validation layer. However, React Hook Form has overtaken Formik in popularity, and React Hook Form's resolver library supports both Zod and Yup equally well. This has eroded Yup's ecosystem advantage significantly.

Zod has become the default validation choice for modern TypeScript frameworks. tRPC uses Zod for input validation with automatic type inference across the API boundary. Next.js Server Actions commonly use Zod for form validation. The T3 Stack (Next.js + tRPC + Prisma + Tailwind) standardises on Zod. These integrations create a flywheel effect — more frameworks adopt Zod, which attracts more developers, which encourages more framework integrations.

Both libraries integrate with React Hook Form, Remix, Astro, and other frameworks through resolver packages. For new projects using modern TypeScript stacks, Zod's ecosystem is now larger and more active. For projects using Formik or older framework versions, Yup's integration may be more established.

Zod's minified bundle size is approximately 13KB gzipped. Yup's is approximately 12KB gzipped. The difference is negligible for most applications. Both libraries tree-shake reasonably well, so unused features do not bloat your bundle in production builds.

Validation performance is comparable for common schemas. Both libraries validate simple object schemas in microseconds. For very large datasets or deeply nested schemas validated in hot paths (thousands of validations per second), benchmarks show minor differences that vary by schema complexity. In practice, validation performance is rarely a bottleneck in web applications — network latency and rendering time dominate.

One area where Zod has improved significantly is parse/transform performance. Zod's .parse() method validates and transforms in a single pass, while Yup's .validate() and .cast() are separate operations that may traverse the schema twice. For schemas with transformations, Zod's single-pass approach is slightly more efficient.

Yup has historically provided better default error messages. Messages like 'this field is required' and 'must be at least 5 characters' are clear and user-friendly. Yup's error objects include a path property that identifies which field failed validation, making it straightforward to display errors alongside form fields.

Zod's error messages are more technical by default — 'Expected string, received number' is accurate but not user-friendly for form validation. Zod addresses this through custom error messages on individual validators and the .refine() method for custom validation logic. The zod-i18n package provides localised error messages. Formatting Zod errors for form display requires slightly more setup than Yup's out-of-the-box messages.

Both libraries support custom error messages on every validation rule. The difference is in defaults — Yup's defaults are ready for form display, while Zod's defaults are more suited to API validation where technical error messages are appropriate. For form validation specifically, Yup requires less error message customisation out of the box.

For new TypeScript projects, choose Zod. The TypeScript type inference alone justifies the choice — maintaining a single source of truth for types and validation eliminates bugs and reduces maintenance effort. Zod's ecosystem integration with tRPC, Next.js, and modern frameworks makes it the natural validation choice for the current TypeScript stack.

Keep Yup if your existing project already uses it extensively, especially with Formik. Migrating validation schemas between libraries is tedious and error-prone, and the benefits of Zod over Yup are not large enough to justify rewriting existing, working validation code. Yup continues to receive updates and is a perfectly capable library.

For JavaScript projects without TypeScript, the advantage gap narrows significantly. Zod's main benefit is type inference, which JavaScript projects cannot use. In this context, Yup and Zod are comparably capable, and team familiarity should drive the choice. That said, most new JavaScript projects in 2026 adopt TypeScript, making Zod the more future-proof selection.