Por que `10.0` dá `z.number()` e `3` dá `z.int()`?

Porque é assim que estão escritos. O JSON tem um único tipo numérico: a única pista sobre o original é o literal, onde um ponto decimal ou um expoente denuncia um flutuante. `10.0` saía como `z.int()`, e o esquema recusava então 10.5 — o registro seguinte. Era um defeito real, corrigido.

`z.int()` existe no Zod 3?

Não, chegou com o Zod 4. Na versão 3 a mesma coisa se escreve `z.number().int()`, e uma substituição basta. Todo o resto da saída — `z.object`, `z.array`, `z.union`, `z.null` — é idêntico entre as duas versões.

O esquema recusa chaves desconhecidas?

Não. `z.object()` tira o que não conhece em vez de falhar: é o padrão do Zod e aqui fica assim. Se uma chave a mais tiver de ser um erro, acrescente `.strict()` você mesmo — é uma decisão sobre a sua API, não algo que uma amostra possa nos dizer.

JSON para Zod — valide na fronteira

Transforme uma amostra JSON em esquemas Zod. Um esquema por objeto, declarado antes do uso, e o z.infer dá o tipo TypeScript a partir da mesma fonte.

Instantâneo Privado Zero cookies

Nome raiz

Entrada JSON

Saída Zod

O que esta ferramenta faz

Uma amostra JSON vira esquemas Zod, um const por objeto.

{ "id": 1, "name": "Ada", "address": { "city": "Paris" } }

import { z } from "zod";

export const AddressSchema = z.object({
  city: z.string(),
});

export const RootSchema = z.object({
  id: z.int(),
  name: z.string(),
  address: AddressSchema,
});

Os filhos vêm primeiro: são constantes de execução, e um esquema precisa existir antes que outro o mencione.

Os números são lidos como foram escritos

z.int() para um inteiro, z.number() para tudo que traga ponto decimal ou expoente:

{ "price": 10.0, "quantity": 3 }

price: z.number(),
quantity: z.int(),

Até há pouco price saía como z.int(): 10.0 é analisado como número inteiro e nada guardava o literal. O esquema recusava então 10.5 — o registro seguinte, muito provavelmente. O JSON tem um único tipo numérico: a forma escrita é o único testemunho do que o produtor queria, e a conversão agora a lê. O defeito foi encontrado ao escrever esta página e corrigido.

Sintaxe do Zod 4

z.int() é a escrita do Zod 4. No Zod 3, escreva z.number().int(); nada mais difere entre as duas versões nesta saída.

O que uma amostra não pode decidir por você

Nada é .optional(). Uma chave vista uma vez pode aparecer; se aparece sempre não está no documento.
null dá z.null(), um esquema que não aceita mais nada. Se o campo for «uma string, às vezes ausente», o .nullable() cabe a você.
Chaves desconhecidas são retiradas, não recusadas, porque é o padrão do Zod. .strict() é uma decisão sobre a sua API.
Um array heterogêneo vira união: [1, "a"] dá z.array(z.union([z.int(), z.string()])), que descreve a amostra com exatidão e talvez seja mais largo que seus dados reais.

Cada um desses pontos é um lugar onde o esquema gerado é só um ponto de partida, e a página diz isso em vez de deixar que você descubra na revisão.

Privado por padrão

Tudo é executado localmente no seu navegador com JavaScript. Os seus dados nunca são enviados para um servidor, o que torna a ferramenta segura para conteúdo sensível e funciona offline.

Perguntas frequentes

Por que `10.0` dá `z.number()` e `3` dá `z.int()`?: Porque é assim que estão escritos. O JSON tem um único tipo numérico: a única pista sobre o original é o literal, onde um ponto decimal ou um expoente denuncia um flutuante. `10.0` saía como `z.int()`, e o esquema recusava então 10.5 — o registro seguinte. Era um defeito real, corrigido.
`z.int()` existe no Zod 3?: Não, chegou com o Zod 4. Na versão 3 a mesma coisa se escreve `z.number().int()`, e uma substituição basta. Todo o resto da saída — `z.object`, `z.array`, `z.union`, `z.null` — é idêntico entre as duas versões.
O esquema recusa chaves desconhecidas?: Não. `z.object()` tira o que não conhece em vez de falhar: é o padrão do Zod e aqui fica assim. Se uma chave a mais tiver de ser um erro, acrescente `.strict()` você mesmo — é uma decisão sobre a sua API, não algo que uma amostra possa nos dizer.