Zod vs Yup vs Joi for Runtime Validation

TL;DR: Static types die at the network boundary. These three libraries pick up where TypeScript stops.

The short version

Static types die at the network boundary. These three libraries pick up where TypeScript stops.

This guide covers the mental model, the patterns that pay off, and the trade-offs that decide whether a technique fits your code.

Working example

Here's a minimal example you can run as-is. Drop it in a fresh file, run it, and trace through it once before reading the rest.

type Result<T, E = Error> =
  | { ok: true; value: T }
  | { ok: false; error: E };

function parseJSON<T>(raw: string): Result<T> {
  try {
    return { ok: true, value: JSON.parse(raw) as T };
  } catch (e) {
    return { ok: false, error: e as Error };
  }
}

const r = parseJSON<{ name: string }>('{"name":"hivecore"}');
if (r.ok) {
  console.log(r.value.name); // narrowed to {name: string}
}

Why this pattern

The shape above shows up in real TypeScript codebases because it satisfies three constraints at once: it stays type-safe, it composes with the rest of the language's idioms, and it leaves a clear trail for the next developer (which, in six months, is you).

When you write the same pattern three times in a project, extract it. When you write it three times across projects, extract it into a shared library.

A common variant

The same idea adapted for a different shape. Notice how the structure stays the same — only the specifics change.

function pluck<T, K extends keyof T>(items: T[], key: K): T[K][] {
  return items.map((it) => it[key]);
}

const users = [
  { id: 1, name: "ada" },
  { id: 2, name: "linus" },
] as const;

const names = pluck(users, "name"); // string[]

Trade-offs to watch

Every pattern has a failure mode. The most common one here is over-application: developers who learn a technique apply it everywhere, including places where simpler code would have been clearer.

Rule of thumb: if the abstraction takes more lines to describe than it saves, the abstraction is wrong.

A more involved example

Once the basic pattern is clear, here's how it composes with surrounding code. Read this one slowly.

type Events = {
  "user.signup": { email: string };
  "order.placed": { id: string; total: number };
};

function emit<K extends keyof Events>(name: K, payload: Events[K]) {
  // dispatch...
}

emit("user.signup", { email: "a@b.co" });    // ok
// emit("user.signup", { id: "x" });          // type error

When to skip it

If the surrounding code is already simple, don't reach for TypeScript-specific cleverness. Boring code is a feature. Save the patterns for places where they actually pay off — usually at module boundaries, in shared libraries, or where the alternative would be 50 lines of repetition.

FAQ

Related reading

• Type Narrowing: Six Techniques That Cover 95% of Real Code
• The TypeScript satisfies Operator in Practice
• TypeScript strict Mode, Flag by Flag
• Postgres Indexing: The 80/20 That Solves Most Slow Queries
• Suspense and Error Boundaries: Production Patterns