Zod to TypeScript

Quick answer: how do you generate TypeScript from Zod?

Use `z.infer<typeof Schema>` when you need a TypeScript type inside the same codebase. Use `z.input` and `z.output` when transforms or coercion make input and output differ. Use the `zod-to-ts` package when you need printed TypeScript declarations from Zod schemas.

Use z.infer for the common case

When the Zod schema is the source of truth, derive the TypeScript type from the schema instead of writing a duplicate interface.

import { z } from "zod";

const UserSchema = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  role: z.enum(["admin", "member"]),
});

type User = z.infer<typeof UserSchema>;

Use z.input and z.output for transforms

When a schema transforms or coerces values, the accepted input type and parsed output type can be different. `z.input` and `z.output` make that distinction visible.

const PageSizeSchema = z.coerce.number().int().min(1).max(100);

type PageSizeInput = z.input<typeof PageSizeSchema>;
type PageSizeOutput = z.output<typeof PageSizeSchema>;

const parsed = PageSizeSchema.parse("25");

When to use zod-to-ts

Use the zod-to-ts package when your build needs TypeScript AST nodes or printed type aliases from Zod schemas. This is different from `z.infer`, which gives a type inside TypeScript but does not print a `.d.ts` style declaration by itself.

import { createTypeAlias, printNode, zodToTs } from "zod-to-ts";

const { node } = zodToTs(UserSchema);
const typeAlias = createTypeAlias(node, "User");

console.log(printNode(typeAlias));

Zod to TS vs TS to Zod

The direction matters. Zod to TypeScript means Zod owns the runtime schema and TypeScript follows. TypeScript to Zod means existing static interfaces are converted into runtime validators.

• Use Zod to TS for new validation-first codebases.
• Use TS to Zod when DTOs already exist as interfaces or type aliases.
• Avoid maintaining both a hand-written type and a hand-written schema for the same boundary.

Unrepresentable Zod features

Printed TypeScript types cannot always express runtime behavior. Transforms, custom schemas, instance checks, and branded runtime rules may need overrides or manual comments.

• Keep runtime-only validation rules in Zod tests.
• Use generated type declarations as documentation, not as proof that runtime parsing happened.
• Review recursive schemas and helper types when printing declarations.

API boundary example

The safest pattern is to parse unknown input with Zod and export the inferred output type for application code. This prevents a static type from pretending the payload was validated.

export function parseUser(payload: unknown): User {
  return UserSchema.parse(payload);
}

export type { User };

Decision checklist

Before chasing the `zod-to-ts` keyword, decide whether the page should satisfy type inference, printed declaration, or opposite-direction converter intent.

• If the user wants `z.infer`, answer with direct TypeScript examples.
• If the user wants the zod-to-ts package, compare package output and limits.
• If the user wants TypeScript to Zod, route them to the FrameworkKit converter.

Zod to TypeScript workflow map

Use FrameworkKit to generate the starter code, then review the output before shipping it in production.

TypeScript and Zod resources

FAQ

Related tools