Zod is a schema declaration and validation library built around TypeScript. A developer describes the expected shape of a value with a composable API of strings, numbers, objects, arrays, unions, optional fields and refinements, then calls a parse method that either returns a validated, typed result or a detailed error describing exactly which field failed and why. Because the TypeScript type is inferred directly from the schema, a single definition serves as both the runtime guard and the compile-time contract.
The library covers primitives, nested objects, discriminated unions, enums, tuples, records, intersections, defaults, transforms, branded types and asynchronous refinements. Error messages are structured and customisable, and coercion helpers convert common string inputs into numbers, dates or booleans at boundaries. Schemas are immutable and composable, so teams can build a small set of shared primitives and extend them into request, response and configuration schemas without repeating validation logic.
It fits API handlers validating request bodies, form libraries checking user input, services reading environment variables or configuration files, and any code that consumes JSON from third-party endpoints, message queues or local storage. Full-stack TypeScript teams often share the same schema between server and client, so the type used in a form, the type used in a route and the type stored in a database stay aligned. It is also commonly used to validate the output of language models before passing it into application logic.
Compared with writing manual type guards, Zod removes the risk of a compile-time interface drifting away from what is actually checked at runtime. Compared with older validation libraries, its inference is designed for TypeScript first and its API is chainable rather than configuration-heavy. Compared with a full framework-level validation layer, it stays a small dependency that can be adopted one boundary at a time, though projects with very large schemas should watch bundle size and parse cost on hot paths.
Parsing is strict by default: unknown keys in objects are stripped, and values that do not match the schema throw rather than silently pass. Teams should decide consciously between parse, safeParse and coercion, and should pin the major version because error formats and some APIs have changed between releases. Schemas describe shape, not business authorisation, so authorisation and rate limiting still belong in the application layer.