Usa el Convertir JSON a Swift Codable gratuito abajo: tus datos nunca salen de tu navegador, todo el trabajo ocurre en tu dispositivo y no se sube a ningún servidor.
De JSON a Structs Swift Codable Sin Trabajo Pesado
Quien desarrolla para iOS conoce bien esta tarea. Una API devuelve JSON y Swift quiere un struct que cumpla Codable, con propiedades de los tipos correctos y CodingKeys donde los nombres JSON difieren del estilo Swift. Escribir eso a mano para una respuesta grande es lento, y es fácil equivocarse en una clave o elegir un tipo incorrecto. Esta herramienta genera los structs desde tu JSON, incluyendo CodingKeys cuando hacen falta, para que puedas concentrarte en lo que tu aplicación hace con los datos.
Pega el JSON, pon el nombre del struct principal y pulsa Convertir. El resultado es un conjunto de structs, cada uno conforme a Codable. Los textos se convierten en String, los enteros en Int, los decimales en Double, los booleanos en Bool y los arreglos en arreglos Swift del tipo del elemento. Las propiedades usan let, lo que encaja con el estilo de tipos por valor habitual en Swift.
CodingKeys, Resueltos por Ti
La convención de Swift usa camelCase para las propiedades, y el JSON a menudo usa otra cosa. Una clave como user_name se convierte en userName en el struct generado, y como eso difiere de la clave original, la herramienta añade un enum CodingKeys que relaciona userName con user_name. Sin esa relación, la decodificación fallaría o dejaría la propiedad vacía, según la configuración de tu decodificador. Con ella, la decodificación simplemente funciona.
Cuando la clave JSON ya coincide con el nombre de la propiedad Swift, no hace falta ninguna entrada en CodingKeys, y la herramienta la omite. Si tu proyecto usa una estrategia de decodificación de claves, como convertir desde snake_case automáticamente, puedes eliminar los enums CodingKeys y poner la estrategia en tu JSONDecoder.
Tipos, Arreglos y Nulos
Las reglas de tipos son directas. Los enteros se convierten en Int, los decimales en Double, los textos siguen siendo textos y los booleanos se convierten en Bool. Los arreglos se convierten en tipos de arreglo Swift: un arreglo de textos se convierte en un arreglo de String, y un arreglo de objetos se convierte en un arreglo de un struct nuevo, con el nombre en singular a partir del campo, así que orders produce un struct Order.
Los valores nulos son el caso límite honesto. Un campo cuya muestra es nula se convierte en un String opcional, con una nota al principio del resultado que te dice que lo cambies por el tipo real. Esa opción por defecto es un marcador, no una afirmación sobre tus datos. Sustitúyela por el tipo real, como Int o un struct propio, cuando sepas qué contiene el campo. Los arreglos vacíos reciben el mismo trato: por defecto son un arreglo de String, y tú sustituyes el tipo del elemento por el real.
Los campos opcionales también merecen una decisión. Si un campo falta a veces, decláralo opcional para que la decodificación no falle cuando está ausente. La herramienta genera propiedades no opcionales porque la muestra muestra el campo presente; después, marca como opcionales las que la documentación diga que lo son.
Structs Anidados y Nombres
Los objetos anidados se convierten en sus propios structs. Un objeto de dirección se convierte en un struct Address. Un arreglo de pedidos se convierte en un arreglo de Order. La estructura del código generado refleja la estructura del JSON, lo que facilita la navegación: el struct principal apunta a los structs anidados, y cada struct anidado contiene sus propios campos. Si dos campos produjeran el mismo nombre de struct, la herramienta numera el segundo para que el código compile, y tú le pones un nombre con significado después.
Pon un buen nombre al struct principal antes de convertir. Un nombre como UserProfile o ApiResponse dice al siguiente desarrollador qué es el struct. Un nombre como Root no dice nada. Lo mismo vale para los structs anidados: si la herramienta numera uno, ese número es una invitación a elegir un nombre mejor, no una respuesta final.
Prueba de los Modelos Generados
Prueba con respuestas reales, no solo con la muestra que convertiste. Decodifica la respuesta más completa que tengas y después decodifica una segunda respuesta distinta del mismo endpoint. Busca tres problemas: campos que cambian de tipo entre respuestas, campos que desaparecen y arreglos vacíos en una respuesta y llenos en otra. Cada problema tiene una solución pequeña: un tipo más amplio, una propiedad opcional o un tipo de elemento corregido.
Ten cuidado con los números. El Int de Swift es de 64 bits en dispositivos modernos, así que las marcas de tiempo son menos un problema que en otros lenguajes. Pero los decimales que a veces llegan como enteros sí merecen revisión: una propiedad Double acepta ambas formas, mientras que una Int falla con la forma decimal.
Revisa también los datos escritos como texto. Las APIs a menudo envían fechas como textos. Una fecha como “2026-10-27” es un String en el struct generado, lo cual es correcto como punto de partida. Si quieres una propiedad Date, añade una estrategia de decodificación de fechas a tu decodificador.
Privacidad
Todo funciona en tu navegador. Tu JSON nunca sale de tu dispositivo, no se guarda y no se envía a ningún servidor. Puedes convertir respuestas con datos reales de usuarios sin riesgo, aunque como siempre conviene mantener los tokens de acceso y las contraseñas fuera del texto pegado. La herramienta es gratuita y no necesita cuenta.