Zod / Pydantic Schema Converter

Paste a schema in Zod, Pydantic, JSON Schema or a TypeScript interface and get the other three, each with a list of the constraints that did not survive.

What are you pasting?

Name for the typeUsed as the class, interface and title.

Your schemaOne type. Types it references must be in the same box — nothing is fetched.

Characters per tokenCharacters per token. An estimate — nothing here runs a tokenizer.

chars

Fields described

Nesting depth 3. Every output below was parsed back and compared with what you pasted; 10 differences came out of that check.

Nesting depth: 3
Zod (TypeScript), characters: 366
Pydantic (Python), characters: 445
JSON Schema, characters: 1,111
TypeScript interface, characters: 244
Estimated tokens, JSON Schema form: ≈ 278

Zod (TypeScript)Read-only. Select all and copy.

Pydantic (Python)Read-only. Select all and copy.

What did not survive the trip to Pydantic (Python):

priority: was required, came back optional
tags: nullable was nothing, came back true
tags: a default of null appeared, which you did not set

JSON SchemaRead-only. Select all and copy.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Ticket",
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "format": "uuid"
    },
    "title": {
      "type": "string",
      "description": "One line, no full stop at the end",
      "minLength": 1,
      "maxLength": 120
    },
    "status": {
      "type": "string",
      "enum": [
        "open",
        "pending",
        "closed"
      ]
    },
    "priority": {
      "type": "integer",
      "minimum": 1,
      "maximum": 5,
      "default": 3
    },
    "tags": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "assignee": {
      "type": [
        "object",
        "null"
      ],
      "properties": {
        "name": {
          "type": "string"
        },
        "team": {
          "type": "string"
        }
      },
      "required": [
        "name",
        "team"
      ],
      "additionalProperties": false
    }
  },
  "required": [
    "id",
    "title",
    "status",
    "priority",
    "assignee"
  ],
  "additionalProperties": false
}

TypeScript interfaceRead-only. Select all and copy.

What did not survive the trip to TypeScript interface:

id: format was "uuid", came back nothing
title: min was 1, came back nothing
title: max was 120, came back nothing
priority: was integer, came back number
priority: min was 1, came back nothing
priority: max was 5, came back nothing
priority: the default 3 was lost

What this assumes: the four dialects go through one intermediate form, which is why they agree with each other — and why the round-trip check means something: each output is fed back into the parser for its own dialect and compared with your input, so the loss lists are produced rather than asserted. Constraints that live in only one dialect are reported and dropped, never approximated in silence. Nested objects become nested classes in Python and inline types in TypeScript. Token figures are characters ÷ 4 and are estimates, not a tokenizer's count. Everything on this page runs in your browser. Nothing you paste is uploaded, logged or sent anywhere.

The reason a schema converter is worth having is not that writing the other three by hand is hard. It is that the four dialects are not equally expressive, and the places they disagree are silent. Zod's .min(1) has no home in a TypeScript interface. A TypeScript union of two object types has no home in any of the other three. Pydantic's gt is exclusive where JSON Schema's minimum is inclusive, so a careless conversion widens what you accept by exactly one value and nothing anywhere complains.

Why the output is parsed back

Because a converter that claims to be lossless is easy to write and impossible to trust. Every output above is read again by the parser for its own dialect and compared with your input, field by field, and the differences are printed underneath it. If the TypeScript block loses your length limits, you see two lines saying so here rather than finding out when a 300-character title reaches the database.

Which one to send to a model

The JSON Schema; the other three are for your own code. Structured output modes take JSON Schema, and the schema goes into the prompt on every request that uses it — so its size is a recurring cost, not a one-off, which is what the character counts above are for. A description on a field earns its tokens when it stops that field being filled with nonsense. A description on every field because a generator put one there does not.

Zod / Pydantic Schema Converter

Why the output is parsed back

Which one to send to a model

The reasoning behind this

Related tools