Zod

Zod is a TypeScript-first schema declaration and validation library. You define a schema once, and Zod both validates untrusted data against it at runtime and infers a precise static TypeScript type from it, so the type system and the runtime check can never drift apart. It ships with zero external dependencies, a roughly 2kb gzipped core bundle, and works identically in Node.js, Deno, Bun, and every modern browser.

Beyond primitive and object schemas, Zod supports unions, discriminated unions, recursive types, refinements, transforms, and built-in JSON Schema conversion, and its .safeParse() API returns a typed result object instead of throwing, making error handling explicit. It has become the de facto standard for runtime validation in the TypeScript ecosystem, with first-class integrations across tRPC, React Hook Form, Next.js Server Actions, and dozens of other frameworks.

What You Get

• A fluent, chainable schema-builder API covering primitives, objects, arrays, unions, discriminated unions, tuples, records, maps, sets, and recursive types
• Automatic static type inference (z.infer, z.input, z.output) so schemas double as your TypeScript types
• .parse() / .safeParse() (and async variants) for throwing or non-throwing validation with a structured ZodError and granular issue list
• Built-in transforms and refinements (.transform(), .refine(), .superRefine()) for coercion and cross-field validation logic
• Native JSON Schema generation (z.toJSONSchema()) and Standard Schema interop for tooling that speaks a common validation contract
• A zod/mini build with a functional, tree-shakeable API for bundle-size-sensitive projects

Common Use Cases

• Validating and typing incoming API request bodies and query parameters in an Express, Fastify, Next.js, or Hono route handler
• Defining end-to-end typesafe contracts in tRPC procedures or Server Actions without hand-written DTOs
• Validating environment variables at process startup so misconfiguration fails fast with a readable error
• Powering form validation and typed form state in React Hook Form, Formik, or Conform integrations
• Parsing and normalizing third-party API responses at the network boundary before they enter application code

Under The Hood

Architecture — Zod’s source (packages/zod/src) is split into a v4/core layer (schema traits, parsing engine, error formatting, JSON Schema conversion, in core.ts, parse.ts, schemas.ts) and a v4/classic layer that layers the familiar chainable z.object()-style API on top of it. A parallel v3 tree preserves the legacy API verbatim for backward compatibility, and v4-mini/mini expose a functional, tree-shakeable variant of the same core. Schema classes are built with a custom $constructor trait system (core.ts) rather than plain ES classes, which lets one definition be shared across the classic, mini, and JSON Schema surfaces without duplicating parsing logic — a deliberate structural choice to support three public API shapes from one validation core.

Tech Stack — Pure TypeScript (~89% of the repo by bytes) with zero runtime dependencies, targeting Node.js, Deno, Bun, and browsers via dual ESM/CJS output built with zshy/tsdown. The repo is a pnpm workspace (packages/zod, packages/docs, packages/bench, packages/integration) with Biome handling linting and formatting and Vitest running the test suite; a check:semver pre-commit hook enforces that version numbers stay in sync across package.json, jsr.json, and the in-source versions.ts.

Code Quality — The v4/core and v4/classic trees each carry their own tests/ directories (168+ test files repo-wide) covering primitive types, refinements, error formatting, and JSON Schema conversion, and AGENTS.md codifies house rules enforced in review: every feature or fix needs a test, no console.log/debugger in shipped code, and tests must stay dense rather than padded with redundant assertions. Error handling is explicit throughout — .safeParse() returns a discriminated-union result rather than relying on exceptions for control flow, and ZodError carries a structured, machine-readable issues array.

API Design — The chainable builder API (z.string().min(3).email()) reads close to prose, and .safeParse()/.parse() give callers a choice between exception-based and result-based error handling depending on context. Getting started requires no boilerplate beyond import * as z from "zod" and one schema declaration — the inferred type is available immediately via z.infer<typeof Schema> with no code generation step. Naming is consistent across the whole surface (.min/.max/.optional/.nullable behave the same on every schema type), and the package even publishes an llms.txt/llms-full.txt and an MCP server specifically to make its API legible to AI coding tools.