JSON es el formato de intercambio de datos dominante en el software moderno — impulsa casi todas las API REST, viene por defecto en las bases de datos documentales NoSQL, sirve como formato de configuración para la mayoría de las herramientas de compilación, y respalda los formatos de mensajes de todos los sistemas importantes de streaming de eventos. A pesar de esa omnipresencia, JSON hace tropezar a los desarrolladores de formas predecibles y específicas: reglas de sintaxis estrictas que difieren de los literales de objeto de JavaScript, casos límite de implementación con números grandes y Unicode, y preguntas sobre cuándo minificar frente a usar formato legible. Las secciones siguientes cubren qué cuenta realmente como JSON válido, la decisión de minificar vs formato legible, los cinco errores de sintaxis más comunes, y consejos prácticos para trabajar con JSON en flujos de trabajo reales.
¿Qué Cuenta como JSON Válido?
JSON (RFC 8259) es más estricto de lo que la mayoría de los desarrolladores esperan, y la rigurosidad atrapa incluso a ingenieros experimentados con regularidad. Todas las cadenas deben usar comillas dobles — las comillas simples y las claves sin comillas son errores de sintaxis, aunque ambas sean válidas en los literales de objeto de JavaScript. Las comas finales después del último elemento de un objeto o arreglo están prohibidas, a diferencia del JavaScript y Python modernos donde se fomentan activamente para un control de versiones más amigable con los diffs. Los comentarios de cualquier tipo no están permitidos en JSON válido — ni los comentarios de línea `//` ni los de bloque `/* */` aparecen en ninguna parte de la especificación. El valor raíz debe ser un objeto, arreglo, cadena, número, booleano o null; los valores de nivel superior fuera de estos tipos (funciones, fechas, undefined) fallan la validación. Los números siguen una gramática específica que excluye `NaN`, `Infinity` e `-Infinity` como valores literales, y excluye los ceros a la izquierda en las partes enteras (excepto el 0 mismo). Estas reglas difieren de los literales de objeto de JavaScript, por lo que el "JSON" escrito a mano a menudo falla la validación cuando se pega en esta herramienta o en un analizador de lenguaje de programación. La conclusión práctica es validar siempre el JSON generado antes de confirmarlo en el control de versiones, enviarlo como respuesta de API, o almacenarlo en una base de datos — un error de análisis tres entornos más abajo es mucho más costoso de depurar que uno detectado de inmediato en el formateador.
Cuándo Minificar vs Usar Formato Legible
La elección entre minificar y usar formato legible tiene una respuesta simple impulsada por la audiencia: minifica para consumo de máquinas, usa formato legible para consumo humano. El consumo de máquinas cubre respuestas de API, almacenamiento en base de datos, colas de mensajes, agregación de registros, transmisión por red, y cualquier contexto donde importan los bytes y no la legibilidad. Una respuesta típica de API REST se reduce entre 25–40% después de la minificación, lo que reduce directamente los costos de ancho de banda, baja la latencia de carga de la página y libera almacenamiento en la base de datos. Combinada con la compresión gzip o brotli en la capa HTTP, el ahorro total puede alcanzar el 80–90% para cargas útiles grandes. El formato legible cubre archivos de configuración versionados, ejemplos de documentación, fragmentos de README, salida de depuración, y cualquier lugar donde un humano realmente leerá el contenido. La elección del estilo de sangría (2 espacios, 4 espacios o tabulaciones) depende de las convenciones del proyecto circundante — usa sangría de 2 espacios para la mayoría de los proyectos de JavaScript, TypeScript y del ecosistema web (el estándar de facto), usa 4 espacios para flujos de trabajo cercanos a Python (siguiendo las convenciones de PEP 8 para el propio Python), y usa tabulaciones para proyectos que imponen un estilo solo de tabulaciones (poco común pero todavía presente en algunos código base de Go y Java antiguos). Esta herramienta usa por defecto sangría de 2 espacios y recuerda tu preferencia entre sesiones. Ordenar Claves es una opción estrechamente relacionada que hace que los archivos JSON sean deterministas — dos objetos lógicamente equivalentes producen una salida idéntica byte por byte, lo que importa para diffs confiables en el control de versiones y para el almacenamiento en caché.
Errores Comunes de JSON
Cinco errores específicos representan la inmensa mayoría de las fallas de análisis de JSON, y reconocerlos a simple vista ahorra un tiempo de depuración significativo. Primero, las comas finales: `{"a": 1, "b": 2,}` es JSON inválido a pesar de ser JavaScript válido y preferido. Elimina la coma después del último valor o haz clic en el botón Reparar. Segundo, las comillas simples: `{'key': 'value'}` es una serialización de diccionario de Python o un literal de objeto de JavaScript, no JSON. Todas las cadenas JSON requieren comillas dobles, y el botón Reparar reemplaza las comillas simples por dobles manejando correctamente los caracteres de escape. Tercero, los comentarios incrustados: JSON no tiene sintaxis de comentarios a pesar del uso generalizado de JSONC ("JSON con Comentarios") en archivos de configuración de editores y herramientas de compilación. JSONC es una extensión de VS Code, no un dialecto conforme a la especificación. Elimina los comentarios antes de analizar, lo que Reparar hace automáticamente. Cuarto, las claves sin comillas: `{name: "Alice"}` es JavaScript válido pero no JSON válido — las claves deben ser cadenas con comillas dobles. Esto se cuela comúnmente al copiar desde código fuente de JavaScript. Quinto, NaN, Infinity e -Infinity: la especificación JSON solo permite números finitos, y estos valores especiales de punto flotante deben representarse como cadenas ("NaN") o valores null según las necesidades de la aplicación posterior. Muchos analizadores de lenguajes los aceptan silenciosamente como extensiones, pero los analizadores conformes a la especificación los rechazan.
Consejos Prácticos para Trabajar con JSON
Un puñado de consejos prácticos de flujo de trabajo cubre la mayoría de las tareas reales de JSON. Usa el Explorador de Árbol para cargas útiles grandes — se renderiza de forma diferida, así que incluso archivos de 10 MB se mantienen ágiles. Busca por nombre de clave para saltar directamente a los datos que necesitas en lugar de desplazarte por miles de líneas de texto formateado. Ordena las claves antes de comparar dos objetos JSON: dos objetos lógicamente equivalentes con las claves en orden diferente se ven distintos en un diff de texto pero se vuelven idénticos byte por byte después de ordenar. Ordenar Claves produce una salida determinista para diffs confiables de control de versiones y generación de claves de caché. Exporta arreglos de objetos planos a CSV para trabajo en hojas de cálculo — si tu JSON es una lista de registros donde cada registro tiene las mismas claves, el conversor a CSV lo convierte en una tabla que puedes abrir directamente en Excel o Google Sheets. Los objetos anidados dentro de las filas se serializan como cadenas JSON en sus celdas, preservando la estructura sin romper la suposición de tabla plana del CSV. Prueba Reparar antes de rechazar JSON inválido — corrige los tres problemas más comunes (comas finales, comentarios, comillas simples) y ahorra tiempo en la depuración manual línea por línea.