Convertir JSON a XLSX

Ahí está toda la distinción con convertir a CSV, y de ella se deriva el resto. Un programa quiere CSV: se lee en flujo, lo importa cualquier rutina y no arrastra formato que estorbe. Una persona quiere un libro que se abra con las columnas en su sitio, la primera fila haciendo de cabecera y cada valor entendido como lo que es.

Si los datos van a una base de datos, a un script o a un proceso de análisis, el CSV es mejor respuesta y esta es la página equivocada. Si van a un compañero que los va a mirar, ordenar y filtrar, y que luego añadirá una columna a mano, entonces es esta.

Un CSV no guarda tipos: guarda texto y deja que el programa adivine. Al abrirlo, Excel decide columna por columna qué es cada cosa, y ahí es donde un código postal de Álava, 01001, se convierte en 1001, y donde 08001 pasa a ser 8001. Lo mismo le ocurre a cualquier referencia de producto que empiece por cero y a los identificadores largos, que a partir de quince dígitos pierden las últimas cifras por la aritmética en coma flotante.

Un XLSX escribe el tipo de cada celda dentro del propio archivo, así que al abrirlo no hay nada que deducir. Si en el JSON el código postal venía como cadena de texto, en la hoja sigue siendo texto y el cero está donde estaba. Y si en el JSON venía como número, el cero ya se había perdido antes de llegar aquí: eso no lo arregla ninguna conversión, se arregla en la exportación que generó el JSON.

Hay una segunda razón, muy española, para no entregar un CSV. En una configuración regional española la coma es el separador decimal y el punto y coma el separador de listas, mientras que casi todo lo que genera un CSV automáticamente usa el punto y la coma. El resultado es conocido: el archivo se abre con todo metido en la columna A, o peor, con los importes leídos como texto.

Con un XLSX ese problema no existe, porque los números viajan como números y la configuración regional solo decide cómo se muestran en pantalla. Es la diferencia entre un archivo que se abre y un archivo que hay que importar con un asistente de tres pasos explicándoselo por escrito a alguien que no debería tener que saberlo.

Cada registro pasa a ser una fila y cada clave pasa a ser una columna, con la fila de cabecera tomada de los propios nombres de las claves. Cuando los registros no comparten exactamente el mismo conjunto de claves, la hoja se construye con todas las columnas que aparecen y deja vacías las celdas de los registros que no tienen nada que poner ahí.

Eso explica una sorpresa habitual: convertir diez registros de prueba puede producir una hoja más estrecha que convertir la exportación completa, simplemente porque en la muestra no aparecían los campos menos frecuentes. Si vas a documentar las columnas para alguien, hazlo sobre el archivo entero y no sobre el recorte.

Un JSON describe un árbol y una hoja de cálculo es una cuadrícula, así que un objeto anidado se aplana: cada hoja del árbol se convierte en una columna y el nombre de la columna es la ruta completa unida por puntos, con los índices de los arrays como un tramo más de esa ruta. Un nivel produce una hoja que cualquiera lee; dos suele seguir siendo manejable.

A partir de ahí se degrada de una forma que se ve a simple vista: las cabeceras se alargan, la hoja se vuelve larguísima hacia la derecha y la mayoría de las celdas están vacías porque cada registro anida a su manera. Si de una exportación aparentemente sencilla salen sesenta columnas, eso no es un fallo: es la forma real de los datos, y una señal de que probablemente deberían seguir siendo JSON.

Un pedido con cinco líneas, una publicación con una lista de etiquetas, una persona con varios domicilios anteriores: ninguno de los tres tiene una representación correcta en una sola fila. Las tres salidas posibles son una columna por posición, una columna con los valores unidos o una fila por elemento, y las tres rompen algo distinto.

Cuando los arrays son el contenido y no un adorno, haz lo que haría una base de datos: una hoja para los registros padre y otra para los hijos, unidas por un identificador. Es más trabajo que una conversión y es la única versión sobre la que alguien puede razonar con una tabla dinámica delante.

El libro que sale de aquí tiene exactamente una hoja. No lleva estilos, ni colores, ni fórmulas, ni anchos de columna ajustados, ni filtros puestos, ni celdas combinadas. Es una tabla desnuda, y decirlo por adelantado evita la decepción de esperar algo con aspecto de informe.

Para lo que sirve esta conversión eso está bien: lo que hace falta es que los datos lleguen enteros y bien tipados, y el formato lo pone quien recibe el archivo en treinta segundos. Si el entregable tiene que ir presentado, el orden correcto es convertir, abrir y dar formato ahí, no buscar un conversor que dé formato por su cuenta.

El nombre de la hoja se toma del nombre del archivo de entrada, sin la extensión, y se recorta a 31 caracteres, que es el máximo que admite el formato. Un JSON llamado «exportacion_clientes_activos_2026_trimestre_1» llega a la pestaña inferior cortado a media palabra.

No afecta a los datos y sí a lo que se entiende de un vistazo. Si el archivo va a circular, renombrar el JSON antes de convertirlo —corto y descriptivo— es más rápido que renombrar la hoja después, y además el nombre del archivo descargado hereda la misma raíz.

Dos comprobaciones que valen para casi todos los casos: que las columnas de identificadores y códigos se lean como texto y no hayan quedado convertidas en números, y que las columnas de fechas tengan el aspecto que esperas y no un número de cinco cifras. Un vistazo de veinte segundos a las primeras filas evita la conversación posterior.

Y mira qué hay dentro, no solo cómo está. Una exportación de una API devuelve todos los campos que la API devuelve, incluidos identificadores internos, marcas de estado y a veces columnas que nadie sabía que existían. Una hoja de cálculo hace todo eso visible de una forma que un JSON no, y es mucho mejor descubrirlo antes de que el archivo salga de la organización que después, sobre todo si dentro hay datos personales.

Una hoja de cálculo es una tabla, así que cualquier cosa que no sea ya una lista de registros se convierte en una única fila en lugar de provocar un error. Un objeto suelto —la respuesta de una consulta, un archivo de ajustes— sale como una hoja de una sola línea con una columna por cada valor final, y eso a veces es exactamente lo que hacía falta.

Conviene saberlo porque explica un resultado desconcertante: si esperabas cien filas y ves una, lo que tienes delante no era una lista, sino un objeto que contenía la lista dentro de una de sus claves. La solución es sacar esa clave a la raíz del archivo antes de convertir, no cambiar de herramienta.

No todo lo que llega en JSON quiere ser una tabla. Un archivo de configuración, la respuesta de un servicio con estructura por niveles o un histórico de conversaciones son árboles, y aplanarlos produce columnas con nombres que nadie quiere leer y un archivo del que no se saca ninguna conclusión.

La parte plana de una exportación —registros de uso, líneas de facturación, listados de una entidad— es justo lo contrario y se convierte muy bien. La decisión razonable es convertir la parte que de verdad necesitas en la hoja y dejar el resto donde está, en vez de convertir la exportación entera y luego borrar cuarenta columnas.

La conversión ocurre en la pestaña, sobre tu propio procesador. El archivo no se envía a ninguna parte, no hay cuenta ni cupo diario, el límite es de 100 MB por archivo y se pueden convertir hasta cien de una vez.

Aquí eso importa más que en la mayoría de las conversiones. Una exportación en JSON es casi siempre la salida en bruto de un sistema —clientes, pedidos, envíos de formularios, cuentas de usuario— y dársela a un conversor ajeno es entregar exactamente los datos de los que la organización responde ante la agencia de protección de datos. No enviarlos a ningún sitio es la forma más simple de no tener que confiar en nadie.