Pega JSON y obtén clases de modelo tipadas, Python dataclass o Pydantic, structs de Go, Java, Kotlin, C#, Swift. Convención de nombres y nulabilidad reales.
🔒 Privado por diseño: tu texto se procesa localmente en tu navegador; nada se sube nunca a ningún servidor.
Escrito y mantenido por Javi Morales·Última actualización
Cómo convertir JSON en clases de modelo tipadas
Pega un objeto JSON (o un array de objetos JSON) en el recuadro de arriba. Una respuesta de API real, un archivo de configuración, o un registro de ejemplo funcionan igual.
Elige tu lenguaje de destino en el menú desplegable: Python (dataclass o Pydantic), Go, Java, Kotlin, C# o Swift.
Para Python, elige opcionalmente el estilo de tipo nulo (Optional[X] o X | None), y activa o desactiva Convert field names según quieras nombres idiomáticos o conservar tus claves JSON originales tal cual.
Pulsa Process JSON to Code, y luego Copy to clipboard para copiar el código de las clases generadas, o pega algo nuevo y vuelve a ejecutarlo.
Clases reales, no una plantilla adivinada
Muchas herramientas de “JSON a código” simplemente imprimen campo: tipo para cada clave y lo dan por terminado, algo que falla en cuanto tu JSON tiene un objeto anidado, un array de registros, un campo que a veces falta, o una clave cuyo nombre idiomático en el lenguaje de destino no coincide con su clave JSON original. Esta herramienta infiere un tipo real para cada campo a partir de tus datos de ejemplo (incluyendo distinguir un int de un float, y fusionando varios elementos de un array en una sola forma unificada y honesta), genera una clase correctamente nombrada para cada objeto anidado y cada array de objetos que encuentra, y (el detalle fácil de hacer mal con confianza) se asegura de que el código generado se pueda seguir deserializando correctamente desde tu JSON real después de renombrar cualquier campo, usando el mecanismo real que tenga tu lenguaje elegido para eso (una etiqueta de struct de Go, un Field(alias=...) de Pydantic, un @JsonProperty de Jackson, un @SerialName de Kotlin, un [JsonPropertyName(...)] de C#, o un enum CodingKeys de Swift).
Convenciones de nombres y nulabilidad, gestionadas por lenguaje
El JSON no tiene un único estilo universal de nombres (una API puede usar snake_case, camelCase, o algo intermedio) y tampoco lo tiene ningún lenguaje de destino. Con “Convert field names” activado (por defecto), cada clave se renombra a lo que ese lenguaje realmente espera: snake_case para Python, camelCase para propiedades de Java/Kotlin/Swift, y PascalCase para campos de Go y propiedades de C#. La nulabilidad recibe el mismo tratamiento real en lugar de un Optional<T> genérico puesto en todas partes: Python recibe Optional[X]/X | None con los campos reordenados correctamente para que un @dataclass normal no falle al importarse (un campo obligatorio nunca puede ir después de uno con valor por defecto), Go recibe un tipo puntero para un valor simple pero nunca para un slice (que ya es naturalmente nulo), Java usa tipos con caja (boxed) en todas partes para que un null nunca provoque un fallo al desempaquetar, Kotlin y Swift reciben un sufijo ? con valores por defecto sensatos, y C# recibe ? tanto en tipos por valor (int?) como en tipos por referencia.
Objetos anidados y arrays de objetos
Un campo que contiene un objeto simple, o un array de objetos, se convierte en su propia clase separada y correctamente nombrada, nunca en un tipo anónimo en línea, ya que la mayoría de estos lenguajes no admiten eso como lo hace TypeScript. El nombre de clase de un campo array se deriva de una forma singular del propio campo (un array friends se convierte en una clase Friend, un array addresses se convierte en Address), y todas las clases se emiten en el orden de dependencia correcto para que un lenguaje como Python (que necesita que una clase ya exista antes de referenciarla en una anotación de tipo) siempre reciba un archivo que realmente carga sin un error de referencia adelantada.
Tu JSON nunca sale de tu dispositivo
Todo (analizar tu JSON pegado, inferir tipos y generar el código final de las clases) se ejecuta con JavaScript normal dentro de tu propia pestaña del navegador. No hay subida, ni llamada a una API, ni ninguna copia de tus datos guardada en ningún sitio que no sea tu dispositivo.
Usos habituales
Convertir una respuesta de API real en un modelo tipado que puedas pegar directamente en un proyecto Python, Go, Java, Kotlin, C# o Swift en lugar de escribirlo campo por campo a mano.
Prototipar rápidamente un modelo de datos a partir de un archivo JSON de ejemplo antes de conectar el código real de deserialización.
Comprobar cómo se infiere realmente el tipo de un campo concreto a partir de tus datos, incluyendo los casos no siempre obvios (una clave que a veces falta, una clave a veces nula, un int frente a un float, un array con tipos genuinamente mixtos).
¿Necesitas validar JSON entrante contra un esquema en lugar de generar clases a partir de él? Mira el Validador de JSON Schema.
¿Solo necesitas embellecer, minificar o validar JSON, sin generar código? Mira el Formateador de JSON.
¿Quieres navegar y editar un documento JSON directamente en vez de generar código a partir de él? Mira el Editor de JSON.
Cómo funciona, en imágenes
JSON a Código (Clases de Modelo) en pleno proceso: la entrada de ejemplo «{"tool":"json-to-code","runsLocally":true,"forma…», Target language en Python dataclass, Python nullable-type style (Python only) en Optional[X], from typing, works on any Python 3.El resultado final: la salida generada «from dataclasses import dataclass from typing im…». El enlace de descarga es una URL blob local: el archivo nunca sale de tu dispositivo.
Preguntas frecuentes
La interfaz (el menú desplegable, los botones) aparece en inglés, ¿y los comentarios que genera el código?
Sí, es una limitación conocida y honesta, no un error de traducción. TextToolShell (el marco compartido que usa esta página) tiene sus propias etiquetas en inglés ("Copy to clipboard", "Process another"), y las opciones del selector de idioma provienen del mismo componente compartido en ambos idiomas. Además, los pequeños comentarios que el código generado incluye a veces (por ejemplo "# Your JSON is a list of these: List[Root]" o el aviso de "no object structure" cuando el JSON no tiene estructura de objeto) son cadenas fijas en inglés dentro del propio módulo, el análisis del JSON, la inferencia de tipos y la generación de clases en sí son totalmente independientes del idioma, incluyendo claves y valores con tildes o la ñ.
¿Qué lenguajes y estilos se admiten exactamente?
Siete, cada uno con su sintaxis real e idiomática en lugar de una plantilla genérica "campo: tipo": Python como `@dataclass` normal O como `pydantic.BaseModel`, structs de Go, Java (un POJO clásico con getters/setters), Kotlin (`data class` con kotlinx.serialization), C# (auto-propiedades con `System.Text.Json`) y Swift (`struct ... : Codable`). Las palabras clave del código generado (class, struct, dataclass, etc.) son sintaxis estándar de cada lenguaje de programación, universal e independiente del idioma de la página, no algo que "traducir".
¿Se sube mi JSON a algún servidor?
No. Tanto el análisis del JSON pegado como la generación del código de las clases ocurren enteramente dentro de tu pestaña del navegador con JavaScript normal, no hay subida ni procesamiento en servidor. El JSON suele contener datos reales (respuestas de API, tokens, registros de bases de datos), así que nada de lo tuyo sale nunca de tu dispositivo.
¿Cómo decide qué campos son opcionales o nulos?
A partir de tus datos de ejemplo reales, no adivinando. Una clave se marca como "opcional" si falta en al menos uno de los objetos de un array de muestras, y se marca por separado como "nula" si está presente pero es `null` en al menos una muestra, se controlan de forma independiente, ya que "a veces ausente" y "a veces presente pero nula" son formas de JSON genuinamente distintas. Un único objeto pegado (no dentro de un array) no tiene otras muestras con las que compararse, así que todas sus claves se toman tal cual están escritas.
¿Por qué la salida de Go añade una etiqueta json:"..." a cada campo?
Porque es necesario, no es una elección de estilo. Los campos de un struct de Go deben empezar en mayúscula para ser exportados, un campo no exportado (en minúscula) es ignorado silenciosamente por `encoding/json` tanto al serializar como al deserializar, así que todos los campos aquí van en PascalCase. Pero `encoding/json` necesita entonces saber a qué clave JSON corresponde realmente ese campo en PascalCase, sobre todo con guiones bajos u otras variaciones que la coincidencia insensible a mayúsculas de `encoding/json` no siempre detecta bien, la etiqueta `json:"clave_original"` deja esa correspondencia explícita y correcta, llevando siempre la clave real y original de tu JSON, sin importar en qué se convirtió el nombre del campo en Go.
¿Qué librería asume la salida de Java, Kotlin, C# o Swift?
Java asume Jackson (`com.fasterxml.jackson.annotation.JsonProperty`), la librería JSON más común en Java, añadida solo cuando el nombre convertido de un campo ya no coincide con la clave JSON original. Kotlin usa `kotlinx.serialization` (`@Serializable`/`@SerialName`), el estándar moderno para Kotlin. C# usa `System.Text.Json`, incluido en .NET Core 3.0+, sin paquete adicional. Swift usa `Codable` normal con un enum `CodingKeys`, también incluido en el lenguaje. Si tu proyecto usa otra librería, puede que necesites cambiar la anotación por su equivalente.
Mi JSON tiene claves en snake_case, ¿los nombres de campo se verán bien en cada lenguaje?
Sí, por defecto: "Convert field names" (activado por defecto) renombra cada clave a la convención propia de ese lenguaje, snake_case para Python, camelCase para propiedades de Java/Kotlin/Swift, PascalCase para campos de Go (siempre, ver la pregunta sobre Go) y C#. Desactiva la casilla para mantener la ortografía original de tus claves tal cual (solo se sanean los caracteres inválidos). En ambos casos, la correspondencia con tu clave JSON real se conserva correctamente, mediante un alias de Field, una etiqueta JSON, `@JsonProperty`, `@SerialName`, `[JsonPropertyName(...)]`, o `CodingKeys`, según el mecanismo del lenguaje elegido.
¿Cuál es la diferencia entre la opción de dataclass de Python y Pydantic?
Un `@dataclass` normal son solo atributos tipados sin ninguna conciencia de JSON incorporada, si un campo se renombra por la opción de convención de nombres, no hay nada nativo del dataclass para volver a mapearlo a tu clave JSON original, así que conserva la ortografía original (desactiva "Convert field names") si planeas construirlo directamente desde un diccionario JSON. `pydantic.BaseModel` SÍ tiene un aliasing de clave JSON real e incorporado (`Field(alias=...)`) (añadido automáticamente siempre que un campo se renombra) así que un modelo Pydantic puede construirse directamente desde tu JSON original sin renombrar (por ejemplo `Root.model_validate(raw_dict)`) mientras te da atributos de Python con buenos nombres para trabajar después.
El valor de un campo es null, o un array está vacío, ¿qué tipo recibe?
Un campo que siempre es null (o un array vacío sin valores de muestra de los que inferir) no puede tener un tipo real inferido, así que recurre honestamente al tipo "cualquier valor" propio de ese lenguaje en lugar de adivinar: `Any` en Python, `interface{}` en Go, `Object` en Java, `JsonElement` en Kotlin, `object` en C#, y una pequeña estructura auxiliar `AnyCodable` autocontenida en Swift (que no tiene ningún tipo incorporado de "cualquier valor JSON", el helper solo se añade al archivo cuando realmente hace falta). El mismo respaldo se aplica a un array con tipos genuinamente mixtos, como `[1, "dos", true]`.
Edita JSON como un árbol expandible, haz clic en cualquier valor para cambiarlo, añade o elimina claves y elementos, sincronizado con una vista de texto.
Formatea, valida y minifica JSON en tu navegador, imprime bonito, o consigue una línea/columna clara ante una entrada inválida. Nada sale de tu dispositivo.