¿El archivo JSON grande no abre? Elige la herramienta según el tamaño

Un JSON de 45 MB se parsea en 249 milisegundos. El medio minuto que esperas viene del renderizado de cinco millones de líneas de texto y 3,5 millones de nodos de árbol. Si confundes ambos, culparás siempre al responsable equivocado.

Uno: mide primero — el parseo nunca es el culpable

Doble clic en una exportación .json de decenas de MB, el editor gira treinta segundos y surge el reflejo: "el parseo de JSON es lento". La medición dice justo lo contrario. En nuestra máquina (Node 22) generamos una muestra de 500.000 registros con cinco campos cada uno (id, email, active, score, tags), 45 MB en formato compacto:

El parseo termina en un cuarto de segundo. El parser acabó su trabajo antes de que sueltes el ratón. Todos los segundos posteriores se gastan en la capa de "mostrar el resultado a un humano": el editor de texto debe organizar cinco millones de líneas, calcular el resaltado de sintaxis y mantener un búfer de deshacer; el visor de árbol debe crear un elemento DOM por cada uno de los 3,5 millones de nodos — y el navegador tropieza alrededor de los cien mil nodos, perdiendo capacidad de respuesta mucho antes del millón.

La conclusión apunta a un lugar completamente distinto: deja de pelear con el renderizado — usa herramientas que no lo muestren todo de golpe.

Dos: por qué se congela — el número de líneas y nodos es el coste real

El tamaño del archivo es solo la superficie. Dos cifras derivadas son las que rompen las herramientas:

1. El número de líneas. Un JSON compacto de 45 MB se convierte en cinco millones de líneas al formatearlo. Abras la parte que abras, el editor debe construir primero la estructura de líneas de todo el archivo, resolver los estados de resaltado y asignar búferes — el coste es proporcional al total de líneas.
2. El número de nodos. Medio millón de registros × (un objeto + cinco campos) son 3,5 millones de nodos. Cualquier visor que construya el árbol completo antes de mostrar paga la misma memoria y tiempo — abras una rama o todas.

De aquí surgen dos implicaciones contraintuitivas. Formatear antes de mirar perjudica — el archivo crece de 45 a 71 MB y el número de líneas se multiplica por cuarenta, carga puramente adicional para la herramienta. Empujar el archivo con cat a la terminal también perjudica — el búfer de scroll se convierte en el nuevo problema; para los primeros bytes basta head -c 2000.

Tres: elige la herramienta según el tamaño — tabla de decisión

Tamaños distintos exigen herramientas completamente distintas. Combinando las mediciones anteriores con guías publicadas (OpenFormatter sitúa la zona cómoda de las herramientas en línea en 2-5 MB; PureJSON estima la memoria tras parsear un documento de 500 MB en 2-4 GB), queda esta tabla:

La herramienta /parse de este sitio cubre el primer escalón: visor de árbol y validación. Los archivos mayores deben ir hacia la aplicación de escritorio, para que decenas de MB nunca se peguen en una página web.

Cuatro: no abras el archivo — pregunta primero su estructura

Ante un JSON grande desconocido, el primer paso no es abrirlo, sino dedicar unos segundos a entender su forma. jq responde tres preguntas en unos 200 ms:

复制# ¿Arriba hay un array o un objeto? ¿Cuántos registros?
jq 'if type == "array" then {type: "array", count: length} else {type: "object", keys: (keys|length)} end' huge.json

# ¿Cómo es el primer registro (solo uno, sin inundación)?
jq '.[0]' huge.json | head -40

# Todos los nombres de campo (del primer registro)
jq '.[0] | keys' huge.json

Conocida la estructura, la mayoría de las peticiones se reducen a "extraer un campo" — ni siquiera hace falta abrir el archivo. Por ejemplo, para obtener el email de cada usuario:

复制jq -r '.[].email' huge.json | less
# Con filtro encima
jq -r '.[] | select(.active == true) | .email' huge.json

La regla es simple: para "ver", visor virtual; para "buscar y extraer", jq. No mezcles ambos papeles en una sola herramienta.

Cinco: el acantilado de memoria — modo normal frente a stream, 150× de diferencia

Sobre la misma muestra de 45 MB, /usr/bin/time -v midió la memoria pico de jq en dos modos:

El modo normal lee el archivo entero y construye el grafo de objetos; el pico de 542 MB confirma la regla "grafo de objetos ≈ 7-12× el tamaño del texto". --stream consume la entrada token a token y mantiene la memoria en un dígito de MB — a cambio de un tiempo total mayor. Pasada la marca del gigabyte, esta diferencia separa "funciona" de "matado por el OOM killer":

复制# Para archivos mayores que la memoria: --stream es el único modo que nunca carga todo
jq --stream -n 'fromstream(1|truncate_stream(inputs))' huge.json

El equivalente en Python es ijson: ijson.items(f, 'item') produce los elementos del array uno a uno con la misma memoria constante. El precio común de estas herramientas es renunciar al acceso aleatorio — el stream avanza solo hacia delante, y una segunda pasada significa releer el archivo.

Seis: hasta dónde llega el navegador — límites del procesamiento local

Las herramientas en línea siguen siendo utilizables, dentro de sus límites. Una pestaña moderna dispone de unos 1-4 GB de memoria; un archivo de 45 MB parseado a grafo más árbol normalmente sobrevive. Varios cientos de MB ya están al borde del acantilado. Al elegir un visor en línea, exige tres cosas:

1. El procesamiento ocurre localmente (lo pegado nunca se envía al servidor) — protege los datos y ahorra tiempo de subida; todas las herramientas de este sitio corren íntegramente en el navegador y funcionan sin conexión;
2. El parseo corre en un Web Worker — el hilo principal no se congela, y un atasco solo cuesta una pestaña, no todo el navegador;
3. Árbol virtualizado o perezoso — las ramas plegadas casi no cuestan; solo se renderiza lo abierto.

En este sitio: /parse sirve para explorar la estructura y localizar errores en archivos de hasta varias decenas de MB; por encima, jq o la aplicación de escritorio, y el navegador se reserva para fragmentos pequeños.

Siete: el formato correcto elimina la mitad del problema

Si puedes influir en cómo se genera el archivo, un visor mejorado es el remedio equivocado — evita que crezca hasta ser "un gigante-array":

• NDJSON/JSONL: un registro por línea. Añadir no reescribe el archivo, y head, grep, tail, split funcionan directamente; un archivo truncado solo pierde la última línea. Nuestra guía JSONL incluye el procedimiento completo para líneas dañadas.
• Exportación paginada: una API que devuelve 100.000 registros debería aceptar un parámetro de página — 100 de golpe es más amable para ambas partes.
• Datos tabulares fuera de JSON: un registro por línea, campos fijos sin anidar — eso es una tabla. CSV o Parquet son más pequeños y con ecosistemas más ricos.

Cifra para recordar: corta por la mitad un array de 500.000 registros y la primera mitad sigue siendo un archivo NDJSON válido (la mitad de los registros sobrevive), mientras que el gigante-array equivalente se pierde entero. Quinientos registros salvados de 501 es mejor que cero.

Ocho: lista de verificación

• Explora la estructura primero con jq '.[0] | keys' o una muestra de 500 registros;
• Nunca formatees solo para abrir el archivo — duplicar líneas solo lo ralentiza;
• Por debajo de 2 MB: visor de árbol en línea; por encima de 20 MB: línea de comandos; por encima de 1 GB: siempre --stream o ijson;
• Comprueba que la herramienta en línea procese localmente (lo pegado no sale del navegador);
• Si controlas el generador, pasa a NDJSON o paginación y elimina el gigante-array en el origen.

Preguntas frecuentes

¿Por qué el editor tarda decenas de segundos en abrir el JSON si el programa lo parsea en 200 ms?

El parseo es código nativo que convierte texto en estructura de datos: 249 ms para nuestra muestra de 45 MB. El editor se atasca en la presentación: cinco millones de líneas que organizar, resaltar y guardar como búfer de deshacer; el árbol construye DOM para 3,5 millones de nodos. Un visor virtual o la extracción directa con jq se saltan todo eso.

¿Se queda jq sin memoria con JSON de más de 1 GB?

En modo normal, sí: carga el documento entero y el grafo de objetos alcanza 7-12× el tamaño del archivo. Con --stream, la entrada se consume token a token: nuestra prueba de 45 MB llegó a un pico de 3,6 MB y la memoria se mantiene plana sea cual sea el tamaño — al precio de un único recorrido secuencial.

¿Hasta qué tamaño manejan los visores JSON en línea?

La mayoría va cómoda hasta 2-5 MB y se degrada claramente por encima de 10 MB. El límite duro es la memoria de la pestaña (1-4 GB), pero ya con varias decenas de MB esperar el parseo y la construcción del árbol es doloroso. Por encima de 20 MB, usa herramientas locales o la línea de comandos.

¿Cómo ver el valor de un campo en un JSON gigante?

Extrae con jq sin abrir el archivo: jq -r '.[].email' huge.json imprime todos los emails; con filtro — jq -r '.[] | select(.active == true) | .email'. Para los primeros registros: jq '.[0:5]' huge.json — órdenes de magnitud más rápido que abrir el archivo.

¿Formatear antes de abrir ayuda?

No. Formatear convierte 45 MB compactos en 71 MB y una línea en cinco millones, añadiendo carga pura al editor y al visor. Reserva el formateo para lo que leerá un humano — y solo si el archivo es bastante pequeño.