Formateador JSONL

Acerca de GeekFormat

Pega aquí JSONL o NDJSON. Las líneas vacías se ignoran automáticamente y cada línea de datos debe ser un objeto JSON completo.

El resultado formateado aparecerá aquí.

Cada línea no vacía debe ser un objeto JSON completo.

Líneas totales: 1Líneas no vacías: 0Líneas válidas: 0Líneas inválidas: 0

Pega JSONL para comenzar a formatear de inmediato.

Una página ligera de formateo JSONL pensada para logs, archivos de sesión y exportaciones en flujo. Pega a la izquierda los objetos JSON separados por saltos de línea y mira a la derecha al instante el resultado formateado de cada registro, viendo directamente qué línea está rota.

Relacionado

Formateo JSON

Reparar JSON

Compresión JSON

JSON Stringify

Validador JSON Schema

¿Qué es el formateo JSONL?

JSONL (JSON Lines) es un formato de texto que organiza los registros JSON por líneas. Su característica central no es «parecerse a JSON», sino que «cada registro ocupa su propia línea». En la ingeniería real esto casi siempre se traduce en que cada línea no vacía es un objeto JSON completo, con los objetos separados por saltos de línea en lugar de envolverlos además en un gran array `[{...},{...}]`.

Esta organización encaja especialmente bien con logs, flujos de eventos, archivos de sesión, exportaciones masivas y procesamiento en flujo: el programa no necesita cargar todo el archivo en memoria, sino que puede consumir los registros línea por línea. Si una línea está rota, se localiza directamente su número, en lugar de contar llaves y buscar comas a ciegas dentro de un array JSON larguísimo.

El formateo JSONL no es lo mismo que el formateo JSON normal. Un formateador normal asume que la entrada es un documento JSON completo; un formateador JSONL debe analizar, validar y reportar errores línea por línea, conservando además la semántica de registros separados por saltos. En logs y archivos de exportación esta diferencia es crucial.

Esta página está diseñada en torno a esa semántica real: a la izquierda se introducen registros de objeto separados por líneas, a la derecha se muestra el resultado formateado por registro, al tiempo que se señalan directamente las líneas rotas, truncadas y no-objeto. Así, al depurar un archivo `.jsonl`, ves «qué registro falla» en lugar de recibir un `SyntaxError` genérico.

Casos de uso

Embellecer línea a línea el JSONL exportado de los logs de una aplicación antes de revisar campo por campo, en lugar de mirar fijamente una larga cadena de objetos comprimidos en una sola línea
Revisar archivos de archivo de sesiones en los que cada línea es un objeto de evento, confirmando que cada registro está completo y es legible
Cuando falla una exportación masiva de un pipeline de datos, una plataforma de tracking o Elasticsearch, localizar rápidamente qué línea del objeto JSON está mal escrita
Al depurar interfaces de salida en flujo, comprobar si el servidor produce realmente «un objeto por línea» de forma continua en lugar de enviar antes de tiempo un objeto a medias
Pegar NDJSON copiado de la terminal, paneles de monitorización o plataformas de logs en la nube: primero ordenar la estructura y luego seguir investigando
Comprobar si en resultados de objetos línea a línea generados por IA se ha colado en alguna línea un array, una cadena o un JSON incompleto
Antes de importar en flujos que dependen de registros por línea como ClickHouse, BigQuery o Kafka Connect, revisar manualmente el contenido JSONL
Al auditar logs de auditoría, eventos de riesgo o flujos de eventos de tracking, comprobar registro a registro si la estructura de los objetos se mantiene estable y coherente
Cuando un archivo JSONL queda truncado o se descarga incompleto, ver al instante qué último objeto no se cerró
Formatear primero el JSON delimitado por líneas exportado por herramientas internas y luego enviarlo a un compañero para revisión de código o comprobación de datos
Antes de escribir un script que analice JSONL, confirmar manualmente los niveles de campos, objetos anidados y posición de los arrays para reducir el tiempo de depuración del script
Al procesar exportaciones históricas con líneas vacías y rotas mezcladas, filtrar primero los problemas de estructura antes de decidir si se convierte a CSV o se importa a una base de datos

Cómo Usar

Pega el contenido JSONL o NDJSON en el área de entrada, asegurándote de que cada línea no vacía sea un objeto JSON independiente
A la derecha se formateará al instante línea por línea y, en las líneas rotas, se indicará el número de línea, el mensaje de error y el registro original
Corrige las líneas correspondientes según las indicaciones hasta que el número de líneas inválidas llegue a cero
Cuando todo sea válido, copia el resultado formateado completo o envía los datos a los scripts, importadores y procesos de análisis posteriores

Características

Analiza JSONL / NDJSON línea por línea, sin necesidad de empaquetar antes manualmente los datos en un array JSON completo como `[{...},{...}]`
Valida según la semántica real de «cada línea no vacía es un objeto JSON», ajustada a formas de datos habituales como logs, flujos de eventos y archivos de sesión
Diseño en dos columnas: entrada con `textarea` a la izquierda y resultado formateado en tiempo real a la derecha, ideal para corregir mientras se revisa
Las líneas rotas muestran directamente el número de línea, el error de análisis y el contenido original, para reparar con rapidez registros truncados, llaves faltantes y errores de concatenación
La copia solo se habilita cuando todas las líneas no vacías son válidas, evitando que datos parcialmente correctos y parcialmente dañados pasen a los procesos posteriores
Incluye contadores de líneas totales, no vacías, válidas e inválidas, para evaluar de un vistazo cuántos registros están dañados en un archivo grande
Incluye datos de ejemplo para probar el formateo JSONL nada más abrir la página
Todo el procesamiento ocurre localmente en el navegador; los logs, eventos de sesión y exportaciones de API no se suben

Formateador JSONL frente a formateador JSON y reparación JSON

Estas herramientas se usan muchas veces seguidas, pero resuelven problemas distintos. Elegir la entrada correcta acelera mucho el trabajo.

Herramienta	Entrada más adecuada	Capacidad principal	Escenario de uso
Formateador JSONL	Un objeto JSON por línea	Validar y embellecer registro a registro	Logs, NDJSON, archivos de sesión, exportaciones en flujo
Formateador JSON	Un objeto o array JSON completo	Embellecer todo el documento JSON	Respuestas de API, archivos de configuración, payloads puntuales
Reparación JSON	Texto JSON con errores de sintaxis o no estándar	Reparar primero la sintaxis y luego seguir procesando	Comas finales, comentarios, problemas de comillas, JSON truncado

Best Practices

Al depurar, mantén la forma JSONL original en lugar de empaquetarla manualmente en un array solo para entenderla

Si el sistema posterior consume JSONL, depura preferiblemente en la forma original de «un registro por línea». Empaquetarla en un array permite pasarla a un formateador normal, pero pierde la semántica de los números de línea originales y dificulta asociar el error a su posición real.

En archivos grandes, revisa primero las últimas líneas

Muchos archivos JSONL no tienen un error estructural en medio, sino que las últimas líneas quedan truncadas por corte de flujo, descarga fallida o escritura incompleta. Mirar primero los últimos registros suele ser más rápido que recorrer el archivo entero desde el principio.

Si la entrada trae comillas simples, comentarios o estilo JSON5, pasa primero por la reparación JSON: ahorrarás tiempo

La página JSONL pone el foco en la validación de objetos por línea; cuando los datos de origen no son JSON estándar de por sí, reparar antes de formatear suele ser más eficiente que corregir manualmente línea por línea un archivo largo.

Al preparar una reimportación, conserva la semántica de transporte de un objeto por línea

El bloque embellecido multilínea de la derecha es más cómodo para las personas, pero si vas a escribir los datos de vuelta en un sistema de logs, una cola de mensajes o un importador, conserva la estructura original de un objeto por línea en lugar de tomar la vista previa como formato de transporte final.

Usa los números de línea como pista principal, en vez de leer todo el archivo a ojo

En una depuración real, lo más rápido suele ser fijar primero el número de línea rota y comparar ese registro con los registros válidos vecinos. Así se ve antes si faltan llaves o comillas, si un campo está truncado o si algún objeto tiene mezclado un tipo incorrecto.

Preguntas Frecuentes

¿Qué diferencia hay entre JSON y JSONL?

El JSON normal suele ser un único objeto o array completo que debe analizarse como un documento entero; en cambio, JSONL (JSON Lines, también llamado NDJSON) contiene un registro independiente por línea, y en la práctica ingenieril lo más habitual es «un objeto JSON por línea». Encaja mejor con logs, flujos de eventos, procesamiento en flujo e importaciones masivas, porque permite leer, escribir y localizar errores línea por línea.

¿Por qué esta página insiste en «un objeto JSON por línea»?

Porque la mayoría de los archivos JSONL del mundo real están organizados así, sobre todo logs, archivos de sesión, flujos de eventos y exportaciones. Tus muestras de archivo también siguen esta forma típica: cada línea es un objeto separado por un salto de línea. La página valida con esta semántica, que se ajusta mucho mejor a la depuración real que aceptar cualquier valor JSON de forma laxa.

¿En qué se diferencia JSONL de un array JSON como `[{...},{...}]`?

Un array JSON es un documento JSON completo que debe leerse entero antes de analizarse; JSONL divide cada objeto en registros de línea independientes, puede leerse en flujo y permite localizar directamente la línea cuando falla un registro. Para archivos de logs grandes y flujos de eventos, JSONL es más adecuado que un array único.

¿Por qué se ignoran las líneas vacías?

Las líneas vacías suelen provenir de copiar y pegar, de la rotación de logs o de edición manual, y no representan registros de datos reales. Ignorarlas reduce el ruido sin renunciar a la comprobación estricta de todas las líneas que sí contienen datos.

¿Qué ocurre si una línea es un array, una cadena o `null`?

La página la considerará una línea inválida, porque el formato objetivo es «cada línea no vacía es un objeto JSON». Si tus datos necesitan almacenar arrays o valores primitivos línea por línea, no se trata del escenario típico de logs JSONL para el que está optimizada esta página.

¿Por qué no se puede copiar todo el resultado cuando hay una línea rota?

Es una interacción deliberadamente conservadora. Solo se permite copiar cuando todas las líneas no vacías son válidas, para evitar que un resultado parcialmente correcto y parcialmente dañado siga pasando a importadores, scripts o compañeros, ahorrando un segundo ciclo de depuración.

¿Puede ayudarme a detectar archivos de logs truncados?

Sí. Muchos problemas de JSONL ocurren en las últimas líneas: por ejemplo, a un objeto le falta `}`, a una cadena le falta la comilla de cierre o el flujo de red se corta a mitad. La página expone directamente la línea rota correspondiente, especialmente útil para descargas incompletas y cortes de salida en flujo.

¿JSONL y NDJSON son lo mismo?

En la inmensa mayoría de contextos ingenieriles pueden tratarse como sinónimos. Ambos indican registros JSON separados por saltos de línea; solo cambia el hábito de nomenclatura.

¿Al formatear JSONL se suben mis datos?

No. Todo el análisis, validación y formateo se ejecuta únicamente en el navegador; los logs, respuestas de API, archivos de sesión y exportaciones de datos no se envían a ningún servidor.

¿Cuándo debería usar el formateador JSON normal en lugar del de JSONL?

Si la propia entrada es un objeto JSON completo o un array, como el cuerpo de una respuesta de API, un archivo de configuración o un paquete de datos tipo `[{...},{...}]`, corresponde usar la página de formateo JSON normal; solo cuando la entrada son registros de objetos separados por saltos de línea encaja mejor esta página de JSONL.

Glosario

JSONL: Formato de texto con registros JSON separados por líneas. La forma más habitual en ingeniería es que cada línea no vacía sea un objeto JSON completo.
JSON Lines: Nombre completo de JSONL y otra denominación habitual; normalmente se considera sinónimo de JSONL.
NDJSON: Newline Delimited JSON, literalmente «JSON delimitado por saltos de línea». En la mayoría de escenarios de logs y pipelines de datos es prácticamente equivalente a JSONL.
Registro por líneas: Disposición de datos en la que cada línea representa un registro completo, adecuada para escritura y lectura en flujo y para localizar errores por línea.
Pretty Print / Formateo legible: Reorganizar un JSON comprimido de una sola línea en una estructura legible con indentación y saltos de línea, para facilitar la inspección manual de los niveles de campos.
Línea rota: Una línea que no es JSON válido o que, aunque puede analizarse, no cumple la estructura esperada (por ejemplo, no es un objeto) y por tanto no constituye un registro JSONL válido.
Flujo truncado: Un log o exportación que se corta a mitad durante la transmisión, el vaciado del búfer o el guardado, dejando el último registro sin cerrar por completo.
Array JSON: En JSON estándar, una colección completa envuelta por `[` y `]`, por ejemplo `[{...},{...}]`. A diferencia de JSONL, debe analizarse como un único documento.

Authoritative References

jsonlines.orgDescripción oficial de JSON Lines
IETFEspecificación oficial JSON RFC 8259