Where do you validate, and how much of that logic should be shared?
A schema library gives you one source of truth for your data shape, inferred types, and error messages across the stack.
One schema, two boundaries
You validate at the boundary: on the client for fast feedback, on the server because you never trust what arrives over the wire. A schema library lets you write that shape once and reuse it on both sides.
Am I validating on the client only, the server only, or both? Which boundaries in my project actually need a check, and do I need the schema to infer my TypeScript types?
Which schema library
Three are worth knowing. Zod is the TypeScript default: types infer straight from the schema, and it has the largest ecosystem and the most examples to learn from. Valibot is modular, so it tree-shakes (the bundler drops the validation code you never import, leaving only the rules you use) and ships a smaller bundle. ArkType writes schemas in TypeScript-like syntax and focuses on fast runtime validation. I lean Zod for most apps: the ecosystem and examples make it the easiest to get unstuck with.
Compare Zod, Valibot, and ArkType for my project: [describe my stack, whether bundle size matters, and how much I care about TypeScript inference]. I am leaning toward Zod. Talk me out of it, or confirm it, and tell me what I would give up either way.
Write the schema once and validate at both boundaries. The client gives feedback; the server is the one you trust.
Additional Resources
Explore these carefully curated resources to deepen your understanding and practice the concepts covered in this lesson.
Zod
DocumentationTypeScript-first schema validation with type inference built in, and the most widely adopted of the three.
https://zod.dev
Valibot
DocumentationModular schemas that tree-shake, so only the validation rules you use ship in your bundle.
https://valibot.dev
ArkType
DocumentationSchemas written in TypeScript-like syntax, with very fast runtime validation.
https://arktype.io