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 de minimizar versus impresión bonita tiene una respuesta simple impulsada por la audiencia: minimizar para el consumo de las máquinas, impresión bonita para el consumo humano. El consumo de la máquina cubre respuestas API, almacenamiento de bases de datos, colas de mensajes, agregación de registros, transmisión de red y cualquier contexto donde los bytes importan y la legibilidad no. Una respuesta típica de API REST se reduce entre un 25 % y un 40 % después de la minificación, lo que reduce directamente los costos de ancho de banda, reduce la latencia de carga de la página y libera almacenamiento en la base de datos. Combinado con la compresión gzip o brotli en la capa HTTP, el ahorro total puede alcanzar entre el 80 % y el 90 % para cargas útiles grandes. Pretty Print cubre archivos de configuración registrados en el control de versiones, ejemplos de documentación, fragmentos README, resultados de depuración y cualquier lugar donde un humano pueda leer el contenido. La elección del estilo de sangría (2 espacios, 4 espacios o tabulaciones) depende de las convenciones del proyecto circundante: use sangría de 2 espacios para la mayoría de los proyectos de JavaScript, TypeScript y ecosistemas web (el estándar de facto), use 4 espacios para flujos de trabajo adyacentes a Python (que coinciden con las convenciones de PEP 8 para el propio Python) y use pestañas para proyectos que imponen un estilo de solo pestañas (poco común, pero aún presente en algunas bases de código de Go y Java anteriores). Esta herramienta tiene por defecto una sangría de 2 espacios y recuerda sus preferencias en todas las sesiones. Sort Keys es una opción estrechamente relacionada que hace que los archivos JSON sean deterministas: dos objetos lógicamente equivalentes producen resultados con bytes idénticos, lo cual es importante para diferencias confiables en el control de versiones y el almacenamiento en caché.
Errores Comunes de JSON
Cinco errores específicos representan la inmensa mayoría de los errores de análisis JSON, y reconocerlos de un vistazo ahorra un tiempo de depuración significativo. Primero, comas al final: `{"a": 1, "b": 2,}` no es JSON válido a pesar de ser JavaScript válido y preferido. Elimine la coma después del último valor o haga clic en el botón Reparar. En segundo lugar, comillas simples: `{'key': 'value'}` es una serialización de dictado 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 comillas dobles conservando los caracteres de escape. En tercer lugar, comentarios incrustados: JSON no tiene sintaxis de comentarios a pesar del uso generalizado de JSONC ("JSON con comentarios") en los archivos de configuración del editor y en las configuraciones de herramientas de compilación. JSONC es una extensión de VS Code, no un dialecto que cumple con las especificaciones. Elimina los comentarios antes del análisis, lo que Repair hace automáticamente. Cuarto, claves sin comillas: `{name: "Alice"}` es JavaScript válido pero no JSON válido; las claves deben ser cadenas entre comillas dobles. Este comúnmente se desliza al copiar desde el código fuente de JavaScript, y Repair puede citar claves de estilo de identificador comunes. Quinto, NaN, Infinity y -Infinity: la especificación JSON solo permite números finitos, y estos valores especiales de punto flotante deben representarse como cadenas ("NaN") o valores nulos según las necesidades de la aplicación posterior. Muchos analizadores de lenguaje los aceptan silenciosamente como extensiones, pero los analizadores que cumplen con las especificaciones 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 — renderiza los primeros niveles de forma diferida, lo que aligera el renderizado inicial, aunque los archivos muy grandes siguen usando memoria del navegador. 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 problemas comunes (comas finales, comentarios, comillas simples y claves sin comillas) y ahorra tiempo en la depuración manual línea por línea.