OpenAPI to Zod

Runs locally in your browser
Input
Output
import { z } from "zod";

export const UserSchema = z.object({
  id: z.string(),
  email: z.string().email(),
  roles: z.array(z.enum(["admin", "editor", "viewer"])),
  profile: ProfileSchema.optional(),
});
export type User = z.infer<typeof UserSchema>;

export const ProfileSchema = z.object({
  website: z.string().url().optional(),
  timezone: z.string().nullable().optional(),
});
export type Profile = z.infer<typeof ProfileSchema>;
openapi to zod

OpenAPI to Zod generator

Paste an OpenAPI or Swagger JSON document and generate Zod validators for `components.schemas` or Swagger `definitions`. FrameworkKit is built for the fast browser workflow: inspect a contract, copy validators, and decide which schemas should move into a TypeScript API boundary before adding a full code-generation step.

Supported OpenAPI and Swagger schemas

The converter handles the schema patterns that usually block a TypeScript integration review: objects, required fields, optional fields, arrays, enums, nullable values, local references, and simple oneOf/anyOf unions. It accepts OpenAPI 3.x component schemas and legacy Swagger 2.0 definitions.

  • OpenAPI 3.x `components.schemas` and local `$ref` component references.
  • Swagger 2.0 `definitions` for older API contracts.
  • Zod validators plus inferred TypeScript types for parsed payloads.
  • Diagnostics for custom formats and complex polymorphic schemas that need review.

OpenAPI 3.0 vs 3.1 nullable fields

Nullable handling is one of the highest-risk conversion details. OpenAPI 3.0 often uses `nullable: true`, while OpenAPI 3.1 can use JSON Schema style type unions such as `type: ["string", "null"]`. FrameworkKit maps supported nullable fields to `.nullable()` and keeps optional properties separate from present-but-null values.

  • Use `.nullable()` when the API can return `null`.
  • Use `.optional()` when the property can be omitted.
  • Use fixtures from real API responses to confirm nullable and optional behavior before shipping.

$ref, shared components, enums, and arrays

Shared OpenAPI components should stay readable after conversion. Local `$ref` values are rendered as references to generated schema exports, enums become closed choices, arrays preserve their item schema, and required arrays control which object keys remain mandatory.

  • Keep component names stable so generated schema names stay stable.
  • Review circular references and deeply nested components before copying output.
  • Check enum values against production payloads, not only against documentation examples.

oneOf and anyOf limits

Simple unions can become Zod unions, but complex oneOf/anyOf structures need a human pass. Discriminators, overlapping object members, and allOf-style inheritance can change runtime behavior if a generator guesses too aggressively.

  • Prefer discriminated unions when the API has a stable type field.
  • Add fixture tests for each union branch.
  • Keep diagnostics visible in pull requests when a schema needs manual review.

Schema coverage checklist

Review required fields, nullable values, enums, arrays, local references, and object strictness before copying generated validators into production code.

  • Use fixtures for successful and failed API responses.
  • Check nullable OpenAPI 3.0 and 3.1 fields carefully.
  • Document unsupported custom formats before release.

Swagger 2.0 migration path

When a team still has Swagger 2.0 definitions, generate Zod schemas from definitions first, then compare the output with the OpenAPI 3 components you plan to publish.

Typed client boundary

The safest workflow is to validate raw network data before it reaches React components, tRPC procedures, cache layers, or service code. Use inferred Zod types after parsing, not before.

FrameworkKit vs openapi-zod-client, Orval, and Kubb

If you are evaluating openapi-zod-client, Orval, Kubb, or other OpenAPI generators, FrameworkKit covers the quick schema-conversion and review workflow without installing a package. Reach for code generation when a typed client should be committed and regenerated in CI; use this converter for fast, private schema inspection and copy-ready Zod validators.

Copy-paste validation recipe

The safest production pattern is small: parse network JSON as unknown, validate with the generated Zod schema, log structured issues when parsing fails, and only expose the parsed value to the rest of the app. This keeps OpenAPI as the contract source while TypeScript receives runtime-checked data.

OpenAPI to Zod online workflow

FrameworkKit is built for the fast OpenAPI to Zod review pass: paste an OpenAPI 3.x or Swagger 2.0 JSON document, inspect generated Zod validators, then copy the schemas that should guard TypeScript API boundaries.

1. Paste OpenAPI JSON

Start with `components.schemas` from OpenAPI 3.x or `definitions` from a Swagger 2.0 document.

2. Generate Zod validators

Objects, required fields, arrays, enums, nullable values, and local `$ref` references become Zod schema code.

3. Validate network data

Parse raw fetch responses as unknown before exposing inferred TypeScript types to UI, cache, or service code.

OpenAPI input and Zod output

A small component schema is enough to check the important conversion details: required keys, enum values, nested references, arrays, and nullable OpenAPI 3.1 fields.

OpenAPI schema input

{
  "openapi": "3.1.0",
  "components": {
    "schemas": {
      "User": {
        "type": "object",
        "required": ["id", "email", "roles"],
        "properties": {
          "id": { "type": "string" },
          "email": { "type": "string", "format": "email" },
          "roles": {
            "type": "array",
            "items": { "type": "string", "enum": ["admin", "editor"] }
          },
          "profile": { "$ref": "#/components/schemas/Profile" }
        }
      },
      "Profile": {
        "type": "object",
        "properties": {
          "timezone": { "type": ["string", "null"] }
        }
      }
    }
  }
}

Zod validator output

import { z } from "zod";

export const ProfileSchema = z.object({
  timezone: z.string().nullable().optional(),
}).strict();

export const UserSchema = z.object({
  id: z.string(),
  email: z.string().email(),
  roles: z.array(z.enum(["admin", "editor"])),
  profile: ProfileSchema.optional(),
}).strict();

export type User = z.infer<typeof UserSchema>;

Nullable, optional, and $ref review

OpenAPI conversion is most error-prone around fields that can be omitted, fields that can be null, and shared component references. Review those rules before copying generated validators into production code.

OpenAPI patternGenerated Zod shapeReview note
Required object propertykey: SchemaKeep required fields mandatory unless the OpenAPI required array is incomplete or generated from stale docs.
Optional object propertykey: Schema.optional()Optional means the property can be omitted; it does not automatically allow null.
OpenAPI 3.0 nullableSchema.nullable()Use fixtures to confirm present-but-null behavior before wiring parse failures to user-facing errors.
OpenAPI 3.1 type null unionSchema.nullable()Keep OpenAPI 3.1 nullable unions separate from missing properties so TypeScript matches runtime behavior.
Local $ref componentReferencedSchemaConfirm component names are stable and review circular or deeply nested references before copying output.
Enum array itemz.array(z.enum([...]))Check enum values against real payloads, not only documentation examples.

FrameworkKit vs OpenAPI code generators

Search intent for OpenAPI to Zod mixes quick browser conversion with repository code generation. Use this comparison to decide when a lightweight schema review is enough and when generated clients belong in CI.

WorkflowBest forTradeoff
FrameworkKit OpenAPI to ZodPrivate browser review, copy-ready validators, and deciding which component schemas need runtime guards.Does not replace a committed generation pipeline when the repo needs regenerated clients on every spec change.
openapi-zod-clientRepository-owned typed clients and Zod schemas generated from an OpenAPI document.Better for CI and long-term codegen, heavier than a quick online schema inspection.
Orval or KubbBroader OpenAPI generation with clients, hooks, mocks, plugins, or framework-specific output.More setup and review surface when the immediate task is only converting schema components to Zod.
Manual Zod schemasSmall contracts, custom parsing rules, or APIs where the OpenAPI document is not trusted.Highest control, but schema drift is easy unless fixtures and contract checks stay current.

What this tool does

Convert OpenAPI or Swagger schema components into runtime validators for TypeScript applications.

Validate API contracts

Convert OpenAPI components into runtime Zod validators for TypeScript services.

Bootstrap typed clients

Generate validators and inferred types from an existing Swagger or OpenAPI document.

Review schema coverage

Inspect required fields, nullable values, enums, arrays, and local references before integration.

OpenAPI to Zod resources

Use API validation guides and examples when turning OpenAPI contracts into Zod validators.

FAQ

Does OpenAPI to Zod support Swagger definitions?

Yes. The current generator accepts OpenAPI components.schemas and Swagger 2.0 definitions in JSON input.

Is YAML supported?

YAML is planned. The live workflow currently focuses on JSON so validation and diagnostics stay predictable.

Is my API schema sent to a server?

No. The current conversion runs in the browser and does not upload pasted OpenAPI documents.

How is this different from openapi-zod-client?

openapi-zod-client is an npm package that generates a full typed fetch client plus Zod schemas inside your codebase. FrameworkKit is a browser-only converter for quickly turning OpenAPI components into Zod validators and inferred types without installing anything. Use openapi-zod-client when you want a generated client committed to your repo, and use this tool for fast schema conversion and review.