Saltar al contenido principal

JSON5 vs JSON

La rigidez de JSON es la característica: RFC 8259 es la razón por la que todos los parsers del mundo se entienden. JSON5 renuncia a parte de esa universalidad a cambio de comodidad humana: comentarios, claves sin comillas, comillas simples, comas finales y números hexadecimales. Reserva JSON para todo lo que lee un programa; permite JSON5 solo en archivos de configuración que todos los consumidores parseen con la misma biblioteca.

Solo local

JSON5 vs JSON: explicación

Todos los archivos JSON que alguna vez han desesperado a alguien lo hacen igual: no puedes explicar por qué existe un campo, no puedes desactivar un bloque temporalmente, y quitar la última coma es un trabajo mecánico que el parser podría perdonar. JSON5 es la respuesta de la comunidad: un superconjunto estricto de JSON, basado en la sintaxis de ECMAScript 5, que añade comentarios, relaja las comillas y tolera las comas finales, además de algunas comodidades numéricas. Un JSON válido siempre es un JSON5 válido; lo contrario nunca es cierto.

La especificación vive en json5.org y no en ningún documento del IETF, y esa ubicación es el resumen honesto del intercambio. La gramática de RFC 8259 es lo que garantiza que un payload escrito en Tokio se parsea exactamente igual en Toronto: una página de reglas, sin dialectos. JSON5 reintroduce la pregunta que el JSON estricto nunca se hace: ¿qué parser, y qué versión de ese parser? Los navegadores traen JSON.parse y nada más, así que JSON5 significa siempre una dependencia.

Por eso la división en la práctica es nítida: JSON para la red y todo lo que se almacena, JSON5 para la configuración mantenida por personas, donde la dependencia de un parser se paga una sola vez y los comentarios se ganan su sitio. Esta página repasa qué añade JSON5, qué cuesta y dónde está la frontera, con las herramientas JSON locales del sitio listas para comprobar cualquiera de los dos lados.

¿Quieres saber en qué punto de la línea de rigor cae tu archivo? El Validador de JSON parsea RFC 8259 localmente y señala la primera construcción que un parser estricto rechaza.

Para los archivos que ya están dentro del subconjunto estricto, el Formateador de JSON normaliza comillas, claves y sangría en tu navegador, sin subir nada.

Qué añade JSON5 en realidad

Las extensiones de JSON5 vienen todas de la sintaxis de literales de objeto de ES5, el lugar de donde salió JSON en su origen. Los comentarios vuelven, como // hasta fin de línea y /* block */. Las claves pueden ir sin comillas cuando son identificadores válidos. Las cadenas pueden usar comillas simples y más secuencias de escape. Los números ganan hexadecimal, punto decimal al principio o al final, signo más delante y los valores especiales Infinity, -Infinity y NaN. Las comas finales se permiten en ambos contenedores.

CaracterísticaJSON (RFC 8259)JSON5
ComentariosNinguno — se eliminaron a propósito// y /* */ permitidos
Claves de objetoSolo cadenas entre comillas doblesIdentificadores válidos sin comillas
Comillas de cadenaSolo comillas doblesSimples o dobles
Comas finalesError de sintaxisPermitidas
NúmerosSolo decimal, sin + inicialHex, +.5, 5., Infinity, NaN
EstándarRFC 8259 / ECMA-404Especificación en json5.org, definida por la biblioteca

El precio: quién puede leer el archivo

JSON.parse rechaza el primer comentario, comilla simple o clave sin comillas que se encuentra: no existe un JSON5 nativo en el navegador ni una plataforma de servidor que lo traiga de serie. Cada consumidor necesita, por tanto, la misma biblioteca, fijada a un comportamiento compatible. En cuanto un documento deja de ser JSON estricto, «cualquier parser sirve» deja de ser verdad, y esa garantía es justo lo que RFC 8259 compraba.

Un precio más sutil es el zoológico de dialectos que crece en ese hueco: JSONC —solo comentarios y comas finales— es lo que tsconfig y VS Code aceptan realmente, y no es JSON5, porque JSONC mantiene las comillas y los números estrictos. Los archivos derivan entre dialectos, los editores discrepan al resaltar la sintaxis, y una actualización de la cadena de herramientas puede convertir una construcción tolerada en un error. El JSON estricto no tiene esa ambigüedad que gestionar.

Dónde encaja cada uno

La división sigue al lector. La configuración escrita y revisada por personas se beneficia de comentarios que explican un campo, interruptores comentados durante la depuración y claves sin comillas que reducen el ruido: ese es el territorio de JSON5, allí donde la cadena de herramientas ya lo soporta. Todo lo que un programa emite o consume —payloads de API, estado almacenado, logs estructurados, mensajes de colas— se queda en JSON estricto, donde la universalidad es justo el punto.

  • Formato de intercambio: JSON, siempre — cualquier consumidor debe poder parsearlo sin configuración compartida alguna.
  • Configuración mantenida por personas: JSON5 o JSONC, si tus herramientas ya lo hablan de forma nativa.
  • Esquemas y documentación: el JSON estricto empuja la explicación hacia los esquemas, porque los comentarios no tienen dónde vivir.
  • Datos en reposo: JSON — sus lectores futuros incluyen herramientas que aún no se han elegido.

Convertir entre ambos

De JSON a JSON5 no cuesta nada: el JSON estricto ya se parsea como JSON5, así que «convertir» es cuestión de estilo, no de estructura. De JSON5 a JSON, la conversión pierde información exactamente donde te lo esperas: los comentarios no tienen destino y desaparecen, e Infinity, -Infinity y NaN no tienen valor JSON, así que se convierten en null o en cadenas. Todo lo demás sobrevive: las claves ganan comillas, las comillas se normalizan y los números hexadecimales llegan como el mismo valor en decimal.

Puedes ver esa frontera con tus propios ojos: pega un archivo JSON5 en un validador estricto y el primer error apunta a la construcción que la cruzó —un comentario, una comilla, una coma final. El diagnóstico también funciona en la dirección contraria: si algún día una herramienta estricta tiene que leer un archivo de configuración, mantenlo dentro del subconjunto estricto desde el primer día, porque rebajarlo después es el trayecto con pérdidas.

Cuándo elegir cada uno

Predeterminado: JSON, y acude a JSON5 solo con un motivo. Ese motivo es un archivo que mantienen personas y que las máquinas solo consumen —configuración de build, feature flags, definiciones de entorno—, combinado con una cadena de herramientas que ya parsea JSON5 de forma nativa. Si tus consumidores son desconocidos, externos o de larga vida, el rigor no es burocracia: es el contrato de la interfaz.

La recomendación se invierte con la misma nitidez: un archivo de configuración que nunca ha necesitado un solo comentario tampoco necesita JSON5, y un archivo JSON5 que un servicio ha empezado a parsear en tiempo de ejecución se ha convertido en silencio en un formato de intercambio, lo que significa que quiere volver a ser JSON.

Preguntas frecuentes

¿Puedo dar formato o validar JSON aquí sin subir el archivo?

Sí. El formateador y el validador se ejecutan por completo en tu pestaña del navegador: el parseo usa el motor JSON del propio navegador contra RFC 8259, ninguna petición sale de la página, la Content-Security-Policy del sitio bloquea las llamadas salientes y el panel Network de DevTools permanece en silencio. Los archivos de configuración nunca salen de tu equipo. El JSON estricto valida; las extensiones de JSON5 aparecen como errores de sintaxis que nombran la construcción exacta.

¿Es JSON5 un estándar oficial?

No en el sentido de un RFC. Está especificado en json5.org y se apoya en su implementación de referencia y en su comunidad, mientras que JSON cuenta con RFC 8259 y ECMA-404. En la práctica, eso significa que no hay lenguaje de conformidad ni registro, y que la interoperabilidad solo queda garantizada si todos comparten el mismo parser: justo lo contrario de la promesa de JSON de que cualquier parser vale.

¿Por qué JSON no admite comentarios?

Douglas Crockford los eliminó a propósito al estandarizar el formato: los fabricantes habían empezado a incrustar directivas de parseo dentro de los comentarios, lo que rompía la interoperabilidad entre implementaciones. Un formato de intercambio de datos debe significar lo mismo para cada lector, así que la gramática se quedó mínima. Las convenciones que sobreviven son claves hermanas como "_comment", o JSONC donde la cadena de herramientas lo permite.

¿Puede JSON.parse procesar JSON5?

No: falla en el primer comentario, comilla simple, clave sin comillas o coma final, lo que derriba de inmediato a la mayoría de los archivos JSON5 reales. Necesitas la biblioteca JSON5 o reescribir antes a JSON estricto. Ojo también con la trampa de JSONC: un parser que acepta comentarios y comas finales sigue sin ser un parser JSON5, y rechazará las comillas simples y los números hexadecimales.

¿Convertir de JSON5 a JSON pierde datos?

Los comentarios, sí: no tienen representación legal en JSON, así que cualquier conversor los descarta por diseño. Infinity, -Infinity y NaN pierden su valor y pasan a ser null o cadenas según el conversor. Todo lo demás sobrevive: las claves sin comillas ganan comillas, las simples se vuelven dobles y los números hexadecimales llegan como el mismo valor en decimal. Si los comentarios importan, el archivo debería quedarse donde los comentarios son legales.

¿Mi configuración debería ser JSON5 o YAML?

Si tu cadena de herramientas ya habla JSON5, quédate: migrar cuesta más de lo que valen los comentarios. Empezando de cero, YAML es el formato de configuración humana más probado, con block scalars, anclas para reutilizar valores y una década de herramientas, al precio de la sensibilidad a la sangría y la inferencia de tipos. La ventaja de JSON5: se queda a un pequeño paso del JSON estricto, así que promover una configuración a datos de máquina es trivial.

¿Dónde puedo leer las normas citadas aquí?

  • RFC 8259 — El formato de intercambio de datos JavaScript Object Notation (JSON)
  • ECMA-404 — La sintaxis de intercambio de datos JSON