¿Por qué ningún campo es opcional?

Porque un documento no puede decirlo. Una clave presente prueba que puede estarlo, no que lo esté siempre. Marcarlo todo obligatorio es al menos una afirmación comprobable con una segunda muestra; inventar un `?` sería afirmar algo sobre datos que nunca enseñaste a la herramienta.

Mi lista de usuarios solo produjo `UsersItem`. ¿Dónde está el tipo de la lista?

Ya está ahí. Un array en la raíz daba solo la interfaz del elemento: había que escribir `UsersItem[]` a mano, y el nombre raíz pedido se ignoraba en silencio. La salida empieza ahora por `export type Users = UsersItem[];`. Era un defecto real, encontrado al escribir esta página.

Dos objetos distintos se llaman ambos `Address`. ¿Qué pasa?

El segundo pasa a `Address2`. Los nombres vienen de las claves, y dos claves de ramas distintas pueden llevar el mismo nombre con formas distintas. Fundirlas daría un tipo falso para ambas; sufijar mantiene cada una honesta, y las formas idénticas siguen compartiendo una definición.

JSON a TypeScript — deja de teclear interfaces

Convierte una muestra JSON en interfaces TypeScript. Los objetos anidados reciben su propio tipo con nombre: un payload pasa a ser un archivo que pegas.

Instantáneo Privado Cero cookies

Nombre raíz

Estilo

Entrada JSON

Salida TypeScript

Qué hace esta herramienta

Una muestra JSON pasa a ser tipos de TypeScript, una interfaz con nombre por objeto.

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

export interface Root {
  id: number;
  name: string;
  address: Address;
}

export interface Address {
  city: string;
}

interface o type, exportado o no, y el nombre de la raíz: los ajustas tú.

Una lista en la raíz ya tiene nombre

Un array de objetos es la muestra más corriente que hay: es lo que devuelve un endpoint de lista. La salida daba solo la interfaz del elemento:

export interface UsersItem {
  id: number;
}

y el nombre raíz que habías escrito no iba a ninguna parte. La lista misma ya tiene nombre:

export type Users = UsersItem[];

export interface UsersItem {
  id: number;
}

Era un defecto, encontrado al escribir esta página y corregido. Los generadores Zod e io-ts de este sitio ya emitían su raíz; TypeScript no.

Mismo nombre, forma distinta

Los nombres de tipo vienen de las claves: dos ramas pueden querer Address las dos. Cuando las formas difieren, la segunda pasa a Address2 en vez de fundirse en un tipo que no encaja con ninguna. Cuando las formas son idénticas, se comparte una sola definición: un Address referenciado dos veces.

Lo que una muestra no puede decir

Nada se marca opcional, y es deliberado: una clave vista una vez dice que puede aparecer, no que aparezca siempre. "nickname": null da nickname: null, porque es todo lo que contiene la muestra; amplíalo tú a string | null cuando lo sepas.

Un identificador de veinte cifras se tipa number, y un número de JavaScript no lo contiene: pasado 2^53 el valor cambia al analizarse. El tipo no miente sobre la muestra, hereda un límite del lenguaje; si el campo es un identificador copo de nieve, ponlo en string y mantenlo fuera de JSON.parse.

Una clave repetida se rechaza

{"a": 1, "a": "x"} daba a: string, ganando la última ocurrencia en silencio. Dos valores, una clave, ninguna forma de decir qué tipo tiene el campo: la conversión se detiene ahora y declara ambiguo el documento. Es la misma respuesta que el validador JSON de aquí ya daba al mismo documento.

Privado por diseño

Todo se ejecuta localmente en tu navegador con JavaScript. Tus datos nunca se suben a un servidor, lo que hace que la herramienta sea segura para contenido sensible y funcione sin conexión.

Preguntas frecuentes

¿Por qué ningún campo es opcional?: Porque un documento no puede decirlo. Una clave presente prueba que puede estarlo, no que lo esté siempre. Marcarlo todo obligatorio es al menos una afirmación comprobable con una segunda muestra; inventar un `?` sería afirmar algo sobre datos que nunca enseñaste a la herramienta.
Mi lista de usuarios solo produjo `UsersItem`. ¿Dónde está el tipo de la lista?: Ya está ahí. Un array en la raíz daba solo la interfaz del elemento: había que escribir `UsersItem[]` a mano, y el nombre raíz pedido se ignoraba en silencio. La salida empieza ahora por `export type Users = UsersItem[];`. Era un defecto real, encontrado al escribir esta página.
Dos objetos distintos se llaman ambos `Address`. ¿Qué pasa?: El segundo pasa a `Address2`. Los nombres vienen de las claves, y dos claves de ramas distintas pueden llevar el mismo nombre con formas distintas. Fundirlas daría un tipo falso para ambas; sufijar mantiene cada una honesta, y las formas idénticas siguen compartiendo una definición.