Structured outputs de LLM. O response_format da OpenAI e o tool-use da Anthropic pegam ambos JSON Schema. Depois de desenhar, você geralmente quer um modelo Pydantic pra validar e acessar campos. Geração de client OpenAPI. Uma spec OpenAPI te dá JSON Schema por body; jeito rápido de chegar a modelos Pydantic sem um gerador completo. Migração Schema → Python. Herdou um sistema com validação JSON Schema pra mover pro Pydantic. Cola cada schema, ganha classe inicial, refina. Scaffolding rápido. Forma rascunhada em JSON num notebook; transforma em modelo real com um colar.

Pydantic v2 vs v1. Default v2. Troca no dropdown se for v1. A saída é ponto de partida. Revisa, especialmente uniões complexas e tipos recursivos. Nomes importam. O campo "Root class name" controla o nome da classe top-level. Sub-classes: title ou nome do campo. Required vs Optional em v2. Required sem default usa ... . Optional cai pra None envolto em Optional[T] .

JSON Schema → Pydantic

Converte JSON Schema em código de modelo Pydantic v2 no seu navegador. Cole o schema, obtenha uma classe Python pronta. Útil pra workflows LLM de structured output.

JSON Schema

Pydantic version

Sample schema

Root class name

Generated Pydantic code

Digite uma entrada acima para ver o resultado.

Para que serve?

JSON Schema e Pydantic são as duas formas principais de descrever um objeto estruturado — JSON Schema é a lingua franca pra OpenAPI, function calling de LLMs e structured outputs; Pydantic é a lib de validação de fato em Python. Frequentemente você tem um e precisa do outro. Esta ferramenta faz a conversão em uma direção: cola um JSON Schema, recebe uma classe Pydantic pronta pra colar num .py.

Quando usar

Structured outputs de LLM. O response_format da OpenAI e o tool-use da Anthropic pegam ambos JSON Schema. Depois de desenhar, você geralmente quer um modelo Pydantic pra validar e acessar campos.
Geração de client OpenAPI. Uma spec OpenAPI te dá JSON Schema por body; jeito rápido de chegar a modelos Pydantic sem um gerador completo.
Migração Schema → Python. Herdou um sistema com validação JSON Schema pra mover pro Pydantic. Cola cada schema, ganha classe inicial, refina.
Scaffolding rápido. Forma rascunhada em JSON num notebook; transforma em modelo real com um colar.

O que a ferramenta entende

type: object com properties + required — classe BaseModel aninhada.
type: array com items — List[X].
Primitivos: string → str, integer → int, number → float, boolean → bool, null → None.
format em string: date-time → datetime, email → EmailStr, uri/url → HttpUrl, uuid → UUID.
enum → Literal[...]; const → Literal[X].
oneOf/anyOf → Union[...]; variante null se dobra em Optional[...].
type: ["string", "null"] → Optional[str].
description → Field(..., description=...).
default → default do campo.
minimum/maximum/minLength/maxLength → Field(ge=..., le=..., min_length=..., max_length=...).
Nomes inválidos pra Python são higienizados e alias= adicionado; modelo configurado com populate_by_name=True.
Objetos aninhados → classes aninhadas, nomeadas por title se houver, senão pelo campo.
$defs/definitions → classes separadas.

O que não entende (ainda)

$ref externo (URLs). Refs locais pra $defs funcionam.
patternProperties — comentário TODO.
additionalProperties com schema — comentário TODO.
Composição allOf multi-base. allOf de um elemento é desempacotado.
Validadores custom de pattern — campo sai, regex não. Adicione @field_validator depois se precisar.

Pegadinhas comuns

Pydantic v2 vs v1. Default v2. Troca no dropdown se for v1.
A saída é ponto de partida. Revisa, especialmente uniões complexas e tipos recursivos.
Nomes importam. O campo "Root class name" controla o nome da classe top-level. Sub-classes: title ou nome do campo.
Required vs Optional em v2. Required sem default usa .... Optional cai pra None envolto em Optional[T].