When to use Zod validation?

TypeScript lies to you at runtime. Not on purpose, but by design. Your types exist only while the code is being compiled, and the moment it runs they are gone. So when a form submits, an API responds, an environment variable loads, or your CMS returns a document, TypeScript has already told you what the shape should be and has no way to check whether reality agrees. Most of the time reality agrees. The bugs live in the times it does not.

Zod is how you close that gap, and the way I use it comes down to one rule that changes everything about whether it is worth the effort.

The rule: one schema, infer the type

Do not write a TypeScript type and a Zod schema separately. Write the Zod schema, and infer the type from it. The schema becomes the single source of truth, and the type is derived from it with z.infer, so the thing you validate at runtime and the thing you type-check at compile time can never drift apart.

1import { z } from "zod";
2
3const UserSchema = z.object({
4  id: z.string().uuid(),
5  email: z.string().email(),
6  displayName: z.string().min(1),
7  role: z.enum(["admin", "editor", "viewer"]),
8});
9
10// The type is derived from the schema, not maintained alongside it.
11type User = z.infer<typeof UserSchema>;
12
13// At the boundary, you parse instead of casting.
14async function getUser(id: string): Promise<User> {
15  const res = await fetch(`/api/users/${id}`);
16  const data = await res.json();
17  return UserSchema.parse(data); // throws if reality doesn't match
18}

The reason this matters is the alternative. The common pattern is to declare an interface User, then trust an as User cast on whatever the API returns. That cast is a lie you are telling the compiler. It silences the type error without checking anything. The Zod version never lies: parse actually inspects the data and throws if it is wrong, and the type you use everywhere else is generated from the exact same definition. You maintain one thing, and it is true at both compile time and runtime.

Once you are working this way, the question "is Zod worth it here?" mostly answers itself, because you are no longer paying a double cost. You are not writing a type and then separately writing validation. You are writing the schema and getting the type for free.

Where to actually apply it: the boundaries

The places that need Zod are the boundaries where data you did not create enters your code. Inside your own application, where data has already been validated and is fully typed, you do not re-validate it at every function call. That would be noise. You validate once, at the edge, and trust the typed data after that.

The edges worth guarding are the obvious ones. User input from forms, because users will always submit something you did not anticipate. API responses, because the API can change, fail, or return an error shape you did not expect. Environment variables, because a missing or malformed one should fail loudly at startup, not mysteriously three screens deep. And CMS content, because editors are human and a field you assumed was always filled in will eventually be empty in production.

That last one matters a lot in the kind of work I do. A schema in the CMS describes intent, but the data that comes back is only as reliable as what an editor actually entered. Validating CMS responses at the boundary turns "why is this page crashing" into a clear, early error that points at the missing field.

For form input specifically, safeParse is usually the better tool than parse, because a failed validation is an expected outcome you want to show the user, not an exception you want to throw:

1const result = ContactSchema.safeParse(formData);
2if (!result.success) {
3  // result.error has structured, field-level messages for the UI
4  return showErrors(result.error.flatten());
5}
6await submit(result.data); // fully typed, fully validated

The honest cost

Zod is not free. It is runtime code that ships to the user, and validating everything everywhere would be both slow and pointless. That is exactly why the boundary rule matters: you pay the cost where untrusted data enters, and nowhere else. Inside that line, your inferred types carry the guarantee without any runtime work.

So my full answer to "when should I use Zod" is two parts. Use it at every boundary where data you do not control enters your application, and nowhere inside that boundary. And whenever you use it, make the schema the source of truth and infer your types from it, because that is the move that turns validation from a chore you maintain in parallel into a single definition that keeps your runtime and your type system honest at the same time. Validation that drifts out of sync with your types is worse than none. Validation derived from your types cannot drift at all.