Si llevas tiempo desarrollando aplicaciones web, APIs REST o archivos de configuración, casi con certeza has trabajado con JSON. Sus siglas significan JavaScript Object Notation y se ha convertido en el formato dominante para transmitir datos estructurados en internet — aunque muchos desarrolladores lo usan a diario sin entender del todo sus reglas y limitaciones.
Un poco de historia
JSON fue formalizado por Douglas Crockford a principios de los 2000, aunque en realidad era un subconjunto de la sintaxis de objetos y arrays de JavaScript que existía desde el origen del lenguaje. La clave fue que un formato de texto liviano y legible resultó mucho más práctico para APIs REST que las alternativas basadas en XML y SOAP que dominaban el software empresarial. El minimalismo de JSON era una ventaja: sin namespaces, sin esquemas obligatorios, sin etiquetas de cierre verbosas.
Para cuando ECMA-404 lo estandarizó en 2013, JSON ya había ganado la batalla. Hoy se usa en todas partes: desde APIs públicas y almacenamiento en el navegador hasta configuraciones de Docker y archivos de configuración de editores.
Las reglas de sintaxis
JSON tiene exactamente seis tipos de valor:
- String — debe ir entre comillas dobles. Las comillas simples no son JSON válido.
"hola mundo" - Number — enteros o decimales, sin ceros a la izquierda (excepto
0.x), sin NaN ni Infinity.42,3.14,-7 - Boolean — solo en minúsculas:
trueofalse - Null — solo en minúsculas:
null - Array — lista ordenada entre corchetes:
[1, "dos", true] - Object — conjunto de pares clave-valor entre llaves, donde cada clave debe ser un string entre comillas dobles:
{"nombre": "Ana", "edad": 30}
JSON no admite comentarios — una de las frustraciones más comunes. Si necesitas comentarios en archivos de configuración, considera JSONC (usado por VS Code en settings.json). Las comas finales también son inválidas: {"a": 1,} fallará en parsers estrictos.
JSON vs XML vs YAML
Antes de JSON, XML era el formato dominante para intercambio de datos, especialmente en entornos empresariales. XML es más expresivo pero muy verboso. JSON gana en compacidad y velocidad de parseo para la mayoría de casos web, aunque XML sigue siendo relevante en documentos, SOAP, RSS, SVG y formatos Office.
YAML es un superconjunto de JSON — todo JSON válido es YAML válido. YAML admite comentarios, strings multilínea y una sintaxis más amigable con indentación significativa. Es común en archivos de configuración (Docker Compose, GitHub Actions, Kubernetes), aunque su sensibilidad al espacio en blanco ha causado suficientes bugs como para que muchos equipos prefieran JSON para configuración.
Errores comunes y trampas
Manejo de fechas: JSON no tiene tipo Date nativo. Las fechas suelen codificarse como strings ISO 8601 ("2026-05-12T10:00:00Z") o como timestamps UNIX (enteros). Documenta siempre qué formato usa tu API.
Precisión numérica: Los números JSON son conceptualmente doubles de 64 bits. Valores superiores a 2^53 pierden precisión al ser parseados por JavaScript. La solución habitual es serializar enteros grandes como strings.
Buenas prácticas
- Valida siempre el JSON antes de pasarlo a otros sistemas. Un validador detecta errores de sintaxis al instante.
- Usa una convención de nombres consistente — camelCase es habitual en APIs JavaScript, snake_case en Python.
- Sé explícito sobre la diferencia entre null y clave ausente — tienen significado semántico distinto.
Un buen formateador de JSON detecta errores de sintaxis de inmediato, muestra la estructura visualmente y permite minificar o embellecer según necesites — por eso tener uno en los marcadores del navegador es uno de los hábitos más útiles que puede desarrollar un programador.