JSON vs YAML vs CSV - Que formato de datos usar y cuando

JSON, YAML y CSV guardan datos estructurados, pero no son intercambiables. El mismo registro de una persona se ve ordenado en los tres - hasta que necesitas direcciones anidadas, booleanos tipados, comentarios en config o una hoja de calculo que tu companero pueda abrir en Excel. Elige el formato equivocado y pierdes tipos, aplastas arboles en columnas incomodas o te encuentras una sorpresa del parser, como YAML convirtiendo el codigo de pais NO en false. Esta guia pone JSON vs YAML vs CSV lado a lado, muestra cuando gana cada uno y enlaza los conversores gratis de ToolsMinify.

El mismo registro en los tres formatos

Empieza con un objeto: un id, un nombre, un flag active y tags. Asi se ve ese registro en cada formato para comparar la sintaxis de un vistazo.

JSON

• {"id": 42, "name": "Ada", "active": true, "tags": ["admin", "beta"]}
• Claves entre comillas, comas entre campos, corchetes para arrays, true/false/null como literales.
• Sin comentarios. Las comas finales son invalidas en JSON estandar.

YAML

• id: 42
• name: Ada
• active: true
• tags:
• - admin
• - beta
• La indentacion define la estructura. Las comillas suelen ser opcionales. Los comentarios empiezan con #.

CSV

• id,name,active,tags
• 42,Ada,true,"admin;beta"
• Una fila de cabecera y luego una fila por registro. Los arrays anidados pasan a una cadena aplanada o columnas extra. No hay tipos nativos mas alla del texto.

Ya miras un array JSON de objetos? Pegalo en el Conversor JSON a CSV para obtener una tabla lista para hoja de calculo. Moviendo config al reves? Usa el Convertidor YAML a JSON antes de un cliente API que solo hable JSON.

JSON: el default de APIs e intercambio

JSON (JavaScript Object Notation) es un subconjunto de la sintaxis de objetos de JavaScript que todo lenguaje importante puede parsear. Objetos, arrays, cadenas, numeros, booleanos y null son de primera clase. La anidacion es ilimitada, asi que un objeto address dentro de un user es natural. Por eso respuestas REST y GraphQL, cuerpos de webhooks y muchos almacenes de config envian JSON.

• Mejor para: cuerpos de peticion y respuesta de API, clientes web y moviles, colas de mensajes, cualquier cosa que deba round-trip por muchos lenguajes.
• Fortalezas: gramatica estricta, tipos predecibles, tooling excelente, facil de minificar y pretty-print.
• Limites: sin comentarios, sin cadenas multilinea sin escapar, sin anclas ni merges. Los humanos editando JSON grande a mano generan diffs ruidosos.

Cuando un payload llega como una linea comprimida, abre el Minificador y Formateador JSON para embellecerlo, validar llaves y volver a minificar antes de publicar.

YAML: config que la gente edita de verdad

YAML (YAML Ain't Markup Language) esta pensado para humanos primero. La indentacion sustituye a la mayoria de llaves. Puedes dejar comentarios con #, escribir bloques multilinea con | o >, y reutilizar bloques con anclas (&name) y alias (*name). Esa combinacion hizo de YAML el default en manifiestos de Kubernetes, Docker Compose, GitHub Actions y muchos archivos de config de apps.

Comentarios y anclas

Los comentarios son la funcion que JSON no tiene. Una linea que empieza con # documenta por que un timeout es 30 segundos sin cambiar los datos en runtime. Las anclas van mas lejos: define un bloque logging compartido una vez con &logging, luego tiralo de el en varios servicios con *logging, opcionalmente superponiendo claves con <<:. Usadas con cuidado, las anclas cortan duplicacion. Usadas sin cuidado, hacen archivos dificiles de leer y sorpresas al hacer merge en Git.

• Mejor para: config de deploy y CI, feature flags que editan humanos, documentos pequenos donde la legibilidad gana al tamano en wire.
• Fortalezas: comentarios, anclas/alias, cadenas multilinea, menos ruido de puntuacion.
• Limites: bugs de indentacion, sorpresas de tipado implicito y una superficie de ataque mayor si parseas YAML no confiable con loaders inseguros.

CSV: tablas planas para hojas de calculo

CSV (Comma-Separated Values) es una cuadricula: columnas y filas. Hojas de calculo, herramientas BI y pipelines de datos lo entienden. No hay objeto anidado, no hay tipo array, y normalmente no hay tipo booleano - todo es texto hasta que tu importador lo castea. Eso esta bien cuando tus datos ya son una tabla de usuarios o pedidos. Se rompe cuando la fuente es un arbol.

Por que CSV pierde tipos y anidacion

• Tipos: "42", 42 y true llegan como cadenas salvo que definas un schema. Los ceros a la izquierda en ids y telefonos los quita Excel.
• Anidacion: una address con street y city pasa a columnas address.street, un blob JSON en una celda o filas padre duplicadas.
• Arrays: tags suele ser una celda con delimitador (admin;beta), que debes partir despues.
• Null vs vacio: una celda vacia puede significar null, cadena vacia o columna ausente - las convenciones difieren.

Si tu fuente es JSON anidado, convierte con criterio con el Conversor JSON a CSV y decide como deben aplanarse arrays y claves anidadas antes de entregar el archivo a una hoja de calculo.

Cuando cada formato es la eleccion correcta

APIs y maquina a maquina

Prefiere JSON. Los clientes esperan application/json, el tooling esta en todas partes y el sistema de tipos basta para la mayoria de contratos. YAML como cuerpo HTTP es raro y suele ser un error. CSV como respuesta de API solo tiene sentido en endpoints de exportacion masiva que alimentan Excel o data warehouses.

Archivos de config

Prefiere YAML (o un formato tipado como TOML) cuando humanos editan el archivo y necesitan comentarios. Prefiere JSON cuando la config se genera, valida con un schema o la editan sobre todo herramientas. Manten documentos YAML pequenos y revisados - anclas profundas y tags custom envejecen mal.

Hojas de calculo y analitica

Prefiere CSV (o un formato de hoja real) cuando el consumidor es Excel, Google Sheets o un SQL COPY. Aplana tu modelo primero. Guarda JSON como sistema de registro y exporta CSV como vista.

Trampas clasicas

El problema de Noruega en YAML

En YAML 1.1, varias cadenas sin comillas se parsean como booleanos: yes, no, on, off, true, false (y algunas variantes locales). El codigo de pais NO para Noruega pasa a boolean false. Cadenas de version como 1.10 pueden pasar a floats. Pon comillas en valores que parezcan booleanos, numeros o fechas cuando en realidad son cadenas: country: "NO". Prefiere parsers YAML 1.2 cuando puedas, y aun asi pon comillas en escalares sospechosos.

Comas CSV dentro de campos entre comillas

Los campos con comas, comillas o saltos de linea deben ir entre comillas dobles. Una comilla dentro de un campo se escapa duplicandola: "Ada ""Lovelace""". Un split ingenuo por comas rompe esas filas. Usa siempre un parser o exportador CSV de verdad - incluso al hacer round-trip con el Conversor JSON a CSV. La configuracion regional tambien importa: algunas regiones usan separador punto y coma mientras Excel sigue esperando comas o al reves.

Otras trampas

• JSON: comas finales y comentarios de literales de objetos JavaScript fallan en parsers estrictos.
• YAML: tabs vs espacios, loaders inseguros que ejecutan tags, y documentos enormes que esconden errores de merge.
• CSV: no hay un unico estandar de encoding, delimitador o finales de linea; documenta siempre UTF-8 y tu separador.

Comparacion lado a lado

• Anidacion - JSON y YAML: arboles naturales. CSV: aplanar o perder estructura.
• Tipos - JSON: string, number, bool, null, array, object. YAML: escalares mas ricos (mas sorpresas). CSV: texto hasta cast.
• Comentarios - JSON: ninguno. YAML: comentarios #. CSV: sin comentarios estandar.
• Edicion humana - YAML suele ganar; JSON vale para archivos pequenos; CSV gana dentro de hojas de calculo.
• Wire / API - JSON es el default. YAML y CSV son casos limite.
• Tooling - convierte con Conversor JSON a CSV y Convertidor YAML a JSON; formatea JSON con el Minificador y Formateador JSON.

Preguntas frecuentes

Es YAML mejor que JSON?

Para config editada por humanos con comentarios, a menudo si. Para APIs e intercambio, JSON es mejor: mas estricto, mas predecible y soportado en todas partes. Muchos equipos escriben YAML y compilan o convierten a JSON para runtime.

Puede CSV representar JSON anidado?

Solo aplanando. Objetos anidados pasan a columnas con punto o cadenas JSON-en-una-celda; arrays pasan a listas delimitadas o filas repetidas. Usa CSV cuando el consumidor necesita una tabla, no cuando necesitas conservar el arbol completo.

Debo guardar config en JSON o YAML?

Si la gente la edita cada semana y deja comentarios, YAML (o TOML). Si un validador de schema o codegen es dueno del archivo, JSON. Evita mezclar ambos para la misma fuente de verdad.

Que es el problema de Noruega en YAML?

NO sin comillas (y tokens similares) puede parsearse como boolean false en YAML 1.1. Pon comillas en codigos de pais y otros escalares tipo cadena, o usa un parser YAML 1.2 que los trate como cadenas.

Como convierto entre estos formatos?

Usa el Convertidor YAML a JSON para llevar config a forma de API, y el Conversor JSON a CSV para exportacion tabular. Embellece o minifica JSON con el Minificador y Formateador JSON. Las tres corren en tu navegador.

Convierte JSON, YAML y CSV en ToolsMinify

Cada herramienta de abajo corre por completo en tu navegador - gratis, sin registro, nada se sube:

• Conversor JSON a CSV - convierte un array JSON de objetos en una tabla CSV descargable.
• Convertidor YAML a JSON - parsea config YAML a JSON para APIs y validadores.
• Minificador y Formateador JSON - pretty-print o minifica JSON y detecta errores de sintaxis pronto.
• Todos los conversores - el indice completo de la categoria.