JSON, CSV o XML: elegir un formato de datos del que no te arrepientas
Tres formatos, tres trabajos distintos. Qué puede expresar cada uno, qué conversiones pierden información y cómo elegir sin arrepentirse después.
Actualizado el 11 de agosto de 20265 min de lectura
Estos tres formatos no son tanto competidores como respuestas a preguntas distintas. El CSV es una tabla. El JSON es un grafo de objetos. El XML es un documento con marcado. Casi todo el dolor del trabajo con datos viene de pedirle a un formato que sea algo que no es —anidamiento dentro de CSV, tablas dentro de XML, comentarios dentro de JSON— y la cura suele ser cambiar de formato en lugar de pelearse con él.
Qué puede expresar cada uno
| CSV | JSON | XML | |
|---|---|---|---|
| Estructura | Filas y columnas planas | Objetos y matrices anidados | Elementos anidados |
| Tipos | Ninguno: todo es texto | Cadena, número, booleano, null | Ninguno de forma nativa; un esquema puede añadirlos |
| Comentarios | No | No | Sí |
| Atributos frente a contenido | No aplica | Sin distinción | Sí, y es una diferencia real |
| Tamaño | El menor | Intermedio: las claves se repiten | El mayor: las etiquetas se repiten dos veces |
| Procesar archivos enormes en flujo | Trivial | Incómodo | Viable |
La fila que más sorprende es la de los comentarios en JSON. La especificación no tiene ninguno, y una línea con // invalida el archivo, razón por la cual tantas herramientas inventaron sus propios dialectos (JSON5, JSONC) para sortearlo. Si un archivo de configuración necesita explicarse, eso es un motivo genuino para preferir otra cosa.
Elegir según el destino
- 1¿Va a una hoja de cálculo, una base de datos o una herramienta de análisis? CSV. Compatible en todas partes, compacto, y la forma tabular es lo que esas herramientas esperan.
- 2¿Va a una API o a una aplicación web? JSON. Lleva tipos, expresa anidamiento y cualquier lenguaje lo analiza sin tener que elegir biblioteca.
- 3¿Hablas con un sistema corporativo o de la Administración? Probablemente XML, porque es lo que dirá la especificación. No te pelees.
- 4¿Un archivo de configuración que la gente editará a mano? JSON no: sin comentarios y con sintaxis implacable. YAML o TOML son más amables.
- 5¿Millones de filas? CSV, procesado línea a línea. Analizar de golpe un JSON de varios gigabytes es un problema de memoria.
Qué pierde cada conversión
| Conversión | Qué se pierde |
|---|---|
| CSV → JSON | Nada estructural, pero todo llega como cadena salvo que se deduzcan tipos |
| JSON → CSV | El anidamiento. Los objetos y las matrices hay que aplanarlos o descartarlos |
| XML → JSON | La distinción entre atributo y elemento, los comentarios y las garantías de orden |
| JSON → XML | Nada, pero el resultado es verboso y necesita una convención de nombres |
| Excel → CSV | Fórmulas, formato y varias hojas: consulta Excel a CSV y JSON |
La fila de JSON a CSV es la que muerde. Aplanar {cliente: {nombre, direccion: {ciudad}}} en columnas necesita una convención —cliente.direccion.ciudad es habitual— y cualquier cosa que sea una lista no tiene una respuesta buena. Si tu JSON está genuinamente anidado, exportarlo a CSV es una decisión con pérdida, no un cambio de formato.
El problema de tipos en sentido contrario es más silencioso e igual de dañino. El CSV no tiene tipos, así que 007 puede llegar como el número 7, 2026-04-03 puede convertirse en una fecha con la configuración regional equivocada y TRUE puede o no convertirse en booleano. Son los mismos fallos descritos en convertir Excel a CSV y JSON, y son inherentes al formato y no a ninguna herramienta concreta.
Formatea, valida y explora en tu propio dispositivo. Los datos de clientes y las cargas de API nunca se suben.
Formatear e inspeccionar JSONHábitos prácticos
- Valida antes de entregar. Una coma final o unas comillas sin escapar serán rechazadas por el sistema receptor con un error que rara vez señala la línea real. El validador lo encuentra en segundos.
- Usa fechas ISO en todas partes.
2026-04-03es inequívoca en cualquier configuración regional y se ordena correctamente como texto. Ninguna otra lo hace. - Codifica siempre en UTF-8. Cualquier otra cosa convierte los nombres con tildes y los símbolos de moneda en caracteres rotos en otro sistema.
- Mantén los identificadores como cadenas. Códigos postales, teléfonos y números de cuenta son etiquetas, no cantidades: tratarlos como números elimina ceros iniciales y redondea valores largos.
- Ordena las claves para comparar. Dos exportaciones de los mismos datos con las claves en distinto orden producen una comparación llena de ruido. El ordenador de claves hace legibles los cambios.
¿Minificar o formatear?
Ambas cosas, en momentos distintos. El JSON formateado —indentado, un valor por línea— es para que lo lean personas y para el control de versiones, donde las comparaciones línea a línea son todo el objetivo. El JSON minificado elimina cada espacio innecesario y es para transmitir, donde suele ahorrar entre un 20 % y un 30 % antes de comprimir.
El error es guardar JSON minificado en un repositorio. Cada cambio aparece entonces como una única línea enorme modificada, y revisarlo es imposible. Guárdalo legible y minifica al construir o al enviar.
Todas estas herramientas funcionan en tu propio dispositivo, algo que importa especialmente en trabajo con datos: una carga JSON o una exportación CSV suele ser el archivo más sensible que maneja una organización, y subirla a un formateador online es una divulgación independientemente de lo que el servicio prometa hacer con ella.
Preguntas frecuentes
¿Debo usar JSON o CSV?
CSV para datos tabulares que van a hojas de cálculo, bases de datos o herramientas de análisis: es compacto y compatible en todas partes. JSON cuando los datos están anidados o cuando importan los tipos, como en una carga de API, porque el CSV no puede expresar una lista dentro de un registro y trata todos los valores como texto.
¿Está el JSON sustituyendo al XML?
En las API web, en gran medida sí: el JSON es más ligero y se corresponde directamente con las estructuras de datos que ya usan los lenguajes de programación. El XML sigue siendo estándar en el ámbito corporativo, público, editorial y en formatos de documento, donde sus esquemas, espacios de nombres y modelo de atributos hacen un trabajo real.
¿El JSON admite comentarios?
No. La especificación no tiene sintaxis de comentarios, y añadir uno invalida el archivo. Por eso existen variantes como JSON5 y JSONC. Si la gente necesita editar y entender el archivo a mano, YAML o TOML son mejores opciones para configuración.
¿Qué pasa con los datos anidados al convertir JSON a CSV?
Hay que aplanarlos, normalmente en nombres de columna con puntos como `cliente.direccion.ciudad`, y las listas dentro de un registro no tienen representación limpia alguna. Si tu JSON está genuinamente anidado, exportarlo a CSV es una decisión con pérdida más que un simple cambio de formato.