Visor de árbol JSON

JSON, el formato de datos que ganó

Douglas Crockford publicó JSON en json.org en 2001 como una alternativa ligera a XML, extrayendo la sintaxis directamente de los literales de objeto de JavaScript. El formato fue estandarizado por primera vez como un Internet-Draft de IETF en la RFC 4627 (julio de 2006), luego revisado como RFC 7159 (marzo de 2014), y finalmente fijado en la RFC 8259 (diciembre de 2017), que es el estándar actual y se mantiene alineado con ECMA-404 (1ª edición octubre de 2013, 2ª edición diciembre de 2017). La RFC 8259 añadió un requisito significativo: la codificación a nivel de red debe ser UTF-8. Dos specs complementarias completan el ecosistema: RFC 6901 «JSON Pointer» (abril de 2013) define la sintaxis /store/book/0/title para direccionar nodos dentro de un documento, y RFC 6902 «JSON Patch» define un documento JSON que describe cambios a aplicar a otro documento JSON. JSON Schema (borrador IETF actual 2020-12) añade validación. Todo lo demás construido encima, JSONC para comentarios en archivos de configuración, JSON5 para sintaxis relajada, NDJSON para streaming, vino después.

Los seis tipos de valores JSON (y lo que falta)

La RFC 8259 §3 define exactamente seis tipos de valores. No hay nada más.

• objeto: conjunto no ordenado de pares nombre-valor delimitados por llaves. Las claves son siempre cadenas.
• array: lista ordenada de valores delimitados por corchetes. Puede contener tipos mixtos.
• cadena: caracteres Unicode entre comillas dobles. Las comillas simples no son JSON legal.
• número: flotante de doble precisión IEEE 754. La spec no garantiza precisión arbitraria; los números más allá de Number.MAX_SAFE_INTEGER = 2⁵³ − 1 = 9 007 199 254 740 991 pierden precisión al parsear.
• true / false: literales booleanos, minúsculas, sin comillas.
• null: el literal null, minúsculas, sin comillas. Una clave con valor null es diferente de una clave ausente.

Lo que JSON no tiene: un tipo de fecha (la convención es una cadena ISO 8601 con zona horaria), comentarios (use un campo de metadatos separado), comas finales, cadenas con comillas simples, números hexadecimales, undefined, NaN o Infinity. Cualquiera de esos hará que JSON.parse lance SyntaxError.

JSON estricto, JSONC, JSON5: cuál es cuál

JSON estricto (RFC 8259) es lo que este visualizador acepta: sin comentarios, sin comas finales, claves entre comillas dobles, cadenas entre comillas dobles. JSONC es una convención de Microsoft enviada en VS Code que permite comentarios de línea // y comentarios de bloque /* ... */ manteniendo todo lo demás estricto; lo ve en tsconfig.json, .vscode/settings.json, y el paquete npm jsonc-parser. JSON5 (2017, https://json5.org) es un superconjunto que añade cadenas entre comillas simples, claves sin comillas, comas finales, números hexadecimales, valores especiales IEEE 754 (NaN, Infinity), y comentarios de línea y de bloque; el paquete npm json5 tiene aproximadamente 10 millones de descargas semanales. NDJSON / JSON Lines (https://jsonlines.org) es una variante de streaming donde cada línea es un documento JSON independiente, usado por shippers de logs y pipelines de ingestión big-data. Elimine comentarios y comas finales antes de pegar si su fuente es JSONC o JSON5.

Donde un visualizador de árbol realmente se gana el sueldo

• Inspección de respuestas API. Stripe, GitHub, Slack, Twilio: cada API moderna devuelve JSON anidado. Pegarlo en un visualizador de árbol hace que la forma sea obvia.
• Archivos de configuración. package.json, tsconfig.json, composer.json, kubeconfig, y la larga cola de configs JSON de proveedores cloud, todos se vuelven más fáciles de auditar como árbol.
• Inspección de exportación de base de datos. Salida de MongoDB find(), filas de PostgreSQL row_to_json, listas de hits de ElasticSearch.
• Descubrimiento de esquema. Cuando una API no tiene documentación, el visualizador de árbol es la documentación.
• Preparación de diff. Antes de ejecutar json-diff o jq entre dos archivos, inspeccione cada uno en un visualizador para detectar manualmente diferencias obvias.
• Inspección de carga útil de webhook. Stripe, GitHub, SendGrid y servicios similares envían todos webhooks JSON. Pegar la carga útil en un visualizador es la forma más rápida de verificar lo que recibirá su endpoint.
• Creación de datos de muestra. Construya una fixture de prueba escribiendo JSON y observe el árbol actualizarse incrementalmente; detecta llaves faltantes antes de guardar el archivo.

Errores comunes al trabajar con JSON

• Comas finales. {"a": 1,} es JavaScript legal pero JSON ilegal. JSON.parse lanza SyntaxError: Unexpected token '}'. Elimínelas o cambie a JSON5.
• Comentarios. // como esto o /* como esto */ son válidos en JavaScript y JSONC pero no en JSON estricto.
• Pérdida de precisión en enteros grandes. Los IDs de Twitter y Stripe pueden exceder 2⁵³; JSON.parse("9007199254740993") devuelve 9007199254740992. Recíbalos como cadenas si la precisión importa.
• Confundir null con ausente. {"foo": null} tiene foo definido como null; {} tiene foo indefinido. La distinción importa para los contratos API y el manejo NULL en bases de datos.
• Claves duplicadas. La RFC 8259 dice que el comportamiento no está definido; en la práctica cada motor JS guarda el último valor. {"a": 1, "a": 2} parsea como {a: 2}.
• Referencias circulares. JSON.stringify lanza TypeError: Converting circular structure to JSON. Aplane ciclos, use un replacer, o use una biblioteca como flatted.
• Cadenas de fecha sin zona horaria. "2026-05-12" es ambiguo; "2026-05-12T18:30:00Z" es ISO 8601 inequívoco en UTC. Incluya siempre el desplazamiento.

Más preguntas frecuentes

¿Qué tan grande puede ser un archivo JSON que este visualizador maneje?

Parsear 1 MB con JSON.parse toma alrededor de 10 ms en V8. Renderizar 100 000 nodos DOM colapsados puede congelar el navegador durante varios segundos. En la práctica, este visualizador es cómodo hasta aproximadamente 5 MB; más allá, espere lag notable durante el render. Para documentos más grandes, use un parser de streaming como stream-json en un Web Worker, o pagine la entrada en trozos.

¿Por qué mi entero grande vuelve mal?

Los números de JavaScript son flotantes de doble precisión IEEE 754. Los enteros hasta 2⁵³ − 1 = 9 007 199 254 740 991 sobreviven a un round-trip exactamente; más allá, la precisión se pierde. Los IDs snowflake de Twitter (64 bits), los IDs de cliente de Stripe, los IDs de transacciones blockchain y muchas claves sustitutas de base de datos exceden este límite. JSON.parse truncará silenciosamente. La solución es recibir los IDs como cadenas (la mayoría de APIs modernas lo hace) o parsear con una biblioteca que soporte BigInt.

¿Qué es JSON Pointer y dónde lo usaría?

La RFC 6901 (abril de 2013) define una sintaxis de ruta para direccionar nodos dentro de un documento JSON: /store/book/0/title selecciona el título del primer libro en el array store. JSON Pointer es la base de JSON Patch (RFC 6902), que expresa deltas de documento como arrays de pares puntero-y-operación. El servidor API de Kubernetes usa JSON Patch para actualizaciones incrementales; también lo hace la API REST de GitHub y muchos otros sistemas.

¿NDJSON / JSON Lines funciona en este visualizador?

No. NDJSON es un valor JSON independiente por línea, sin array contenedor. JSON.parse sobre el archivo entero lanza porque la segunda línea empieza donde termina el primer objeto. Envuelva todo el contenido en [ y ] y reemplace cada nueva línea entre objetos con una coma, o pegue una línea a la vez, o use un visualizador NDJSON dedicado.

¿Mi JSON se envía a alguna parte?

No. JSON.parse se ejecuta en el motor JavaScript de su navegador, el árbol se renderiza como nodos DOM localmente, y no se envía ninguna copia de sus datos por la red. Esto es seguro para respuestas API con secretos, datos de cliente o PII. Abra la pestaña Red en DevTools y pegue una muestra: verá cero solicitudes salientes durante el parsing y renderizado.