Formatador JSONL

Sobre o GeekFormat

Cole JSONL ou NDJSON aqui. Linhas em branco são ignoradas automaticamente, e cada linha de dados deve ser um objeto JSON completo.

O resultado formatado aparecerá aqui.

Cada linha não vazia deve ser um objeto JSON completo.

Total de linhas: 1Linhas não vazias: 0Linhas válidas: 0Linhas inválidas: 0

Cole JSONL para começar a formatar imediatamente.

Uma página leve de formatação JSONL voltada para logs, arquivos de sessão e exportações em fluxo. Cole à esquerda os objetos JSON separados por quebras de linha e veja à direita na hora o resultado formatado de cada registro, enxergando diretamente qual linha está com problema.

Sugestões Relacionadas

Formatador JSON

Reparar JSON

Comprimir JSON

JSON Stringify

Validador JSON Schema

O que é formatação JSONL?

JSONL (JSON Lines) é um formato de texto que organiza registros JSON por linhas. Sua característica central não é «parecer JSON», e sim «cada registro ocupa uma linha própria». Na engenharia real isso quase sempre significa que cada linha não vazia é um objeto JSON completo, com os objetos separados por quebras de linha em vez de serem ainda embrulhados em um grande array `[{...},{...}]`.

Essa organização combina especialmente com logs, fluxos de eventos, arquivos de sessão, exportações em lote e processamento em fluxo: o programa não precisa carregar o arquivo inteiro na memória, basta consumir os registros linha por linha. Se uma linha está quebrada, seu número é localizado diretamente, em vez de contar chaves e procurar vírgulas às cegas dentro de um array JSON enorme.

Formatação JSONL não é a mesma coisa que formatação JSON comum. Um formatador comum pressupõe que a entrada é um documento JSON completo; um formatador JSONL precisa analisar, validar e apontar erros linha por linha, preservando ainda a semântica dos registros separados por linha. Para logs e arquivos de exportação, essa diferença é fundamental.

Esta página foi desenhada em torno dessa semântica real: à esquerda entram registros de objeto separados por linhas, à direita aparece o resultado formatado por registro, enquanto linhas inválidas, truncadas e que não são objetos são apontadas diretamente. Assim, ao investigar um arquivo `.jsonl`, você vê «qual registro tem problema» em vez de receber um `SyntaxError` genérico.

Casos de uso

Embelezar registro por registro o JSONL exportado dos logs de um aplicativo antes de investigar campo por campo, em vez de encarar uma longa sequência de objetos espremidos em uma única linha
Conferir arquivos de sessão em que cada linha é um objeto de evento, confirmando que cada registro está completo e legível
Quando falha uma exportação em massa de um pipeline de dados, plataforma de rastreamento ou Elasticsearch, localizar rápido qual linha do objeto JSON foi mal escrita
Ao depurar interfaces de saída em fluxo, verificar se o servidor realmente produz «um objeto por linha» de forma contínua, em vez de despejar antes da hora um objeto pela metade
Colar NDJSON copiado do terminal, painéis de monitoramento ou plataformas de log na nuvem: primeiro organizar a estrutura e depois continuar a investigação
Conferir se, em resultados de objetos linha a linha gerados por IA, alguma linha misturou por engano um array, uma string ou um JSON incompleto
Antes de importar para fluxos que dependem de registros por linha, como ClickHouse, BigQuery ou Kafka Connect, revisar manualmente o conteúdo JSONL
Ao auditar logs de auditoria, eventos de risco ou fluxos de eventos de rastreamento, verificar registro por registro se a estrutura dos objetos se mantém estável e consistente
Quando um arquivo JSONL fica truncado ou é baixado de forma incompleta, ver na hora qual é o último objeto que não foi fechado
Formatar primeiro o JSON delimitado por linhas exportado por ferramentas internas e depois enviá-lo a um colega para revisão de código ou conferência de dados
Antes de escrever um script que analisa JSONL, confirmar manualmente níveis de campos, objetos aninhados e posição dos arrays para reduzir o tempo de depuração do script
Ao lidar com exportações históricas que misturam linhas vazias e inválidas, primeiro filtrar os problemas de estrutura antes de decidir se segue conversão para CSV ou importação em banco

Como Usar

Cole o conteúdo JSONL ou NDJSON na área de entrada, garantindo que cada linha não vazia seja um objeto JSON independente
À direita ele será formatado na hora linha por linha e, nas linhas inválidas, serão indicados o número da linha, a mensagem de erro e o registro original
Corrija as linhas apontadas seguindo as dicas até que o número de linhas inválidas chegue a zero
Depois de confirmar que tudo está válido, copie o resultado formatado completo ou envie os dados para scripts, importadores e processos de análise seguintes

Recursos

Analisa JSONL / NDJSON linha por linha, sem precisar empacotar antes os dados manualmente em um array JSON completo como `[{...},{...}]`
Valida pela semântica real de «cada linha não vazia é um objeto JSON», alinhada a formatos comuns como logs, fluxos de eventos e arquivos de sessão
Layout em duas colunas: entrada em `textarea` à esquerda e resultado formatado em tempo real à direita, ideal para corrigir enquanto acompanha
Linhas inválidas mostram diretamente o número da linha, o erro de análise e o conteúdo original, para reparar rápido registros truncados, chaves ausentes e erros de concatenação
A cópia só é liberada quando todas as linhas não vazias são válidas, evitando que dados parcialmente corretos e parcialmente corrompidos sigam para os processos seguintes
Inclui contadores de linhas totais, não vazias, válidas e inválidas, para avaliar de relance quantos registros estão quebrados em um arquivo grande
Traz dados de exemplo para você testar a formatação JSONL já na primeira abertura
Todo o processamento acontece localmente no navegador; logs, eventos de sessão e exportações de API não são enviados

Formatador JSONL vs formatador JSON vs reparo JSON

Essas ferramentas são usadas muitas vezes em sequência, mas resolvem problemas diferentes. Escolher a entrada certa acelera bastante o trabalho.

Ferramenta	Entrada mais adequada	Capacidade principal	Cenário de uso
Formatador JSONL	Um objeto JSON por linha	Validar e embelezar registro por registro	Logs, NDJSON, arquivos de sessão, exportações em fluxo
Formatador JSON	Um objeto ou array JSON completo	Embelezar o documento JSON inteiro	Respostas de API, arquivos de configuração, payloads pontuais
Reparo JSON	Texto JSON com erros de sintaxe ou fora do padrão	Primeiro corrigir a sintaxe e depois seguir	Vírgulas finais, comentários, problemas de aspas, JSON truncado

Best Practices

Ao depurar, mantenha a forma original do JSONL em vez de empacotá-lo manualmente em um array só para entender

Se o sistema seguinte consome JSONL, depure de preferência na forma original de «um registro por linha». Empacotar em um array até permite usar um formatador comum, mas perde a semântica dos números de linha originais e dificulta mapear o erro de volta à sua posição real.

Em arquivos grandes, olhe primeiro as últimas linhas

Muitos arquivos JSONL não têm erro de estrutura no meio; as últimas linhas é que ficam truncadas por interrupção de fluxo, download falhado ou gravação incompleta. Examinar primeiro os últimos registros costuma ser mais rápido do que percorrer o arquivo inteiro desde o começo.

Se a entrada traz aspas simples, comentários ou estilo JSON5, passar antes pelo reparo JSON economiza tempo

A página JSONL foca na validação de objetos linha por linha; quando os dados de origem já não são JSON padrão, reparar antes de formatar costuma ser mais eficiente do que editar manualmente cada linha de um arquivo longo.

Ao preparar uma reimportação, preserve a semântica de transporte de um objeto por linha

O bloco embelezado multilinha à direita é mais confortável para leitura humana, mas se você vai escrever os dados de volta em um sistema de logs, fila de mensagens ou importador, mantenha a estrutura original de um objeto por linha em vez de tratar a prévia como formato final de transporte.

Use os números de linha como pista principal, em vez de ler o arquivo inteiro a olho nu

Numa depuração real, o caminho mais rápido geralmente é primeiro fixar o número da linha inválida e comparar esse registro com os registros válidos vizinhos. Assim você vê mais rápido se faltam chaves ou aspas, se um campo foi truncado ou se algum objeto misturou um tipo errado.

Perguntas frequentes

Qual a diferença entre JSON e JSONL?

O JSON comum normalmente é um objeto ou array inteiro, a ser analisado como um documento completo; por sua vez, o JSONL (JSON Lines, também chamado de NDJSON) traz um registro independente por linha, e na prática de engenharia o mais comum é «um objeto JSON por linha». Ele combina melhor com logs, fluxos de eventos, processamento em fluxo e importações em lote, porque permite ler, escrever e localizar erros linha por linha.

Por que esta página enfatiza «um objeto JSON por linha»?

Porque a maioria dos arquivos JSONL do mundo real é organizada assim, especialmente logs, arquivos de sessão, fluxos de eventos e exportações. Suas amostras de arquivo também seguem essa forma típica: cada linha é um objeto separado por uma quebra de linha. A página valida com essa semântica, muito mais alinhada à depuração real do que aceitar de forma ampla qualquer valor JSON.

Em que o JSONL é diferente de um array JSON como `[{...},{...}]`?

Um array JSON é um documento JSON completo que precisa ser lido inteiro antes de ser analisado; o JSONL divide cada objeto em registros de linha independentes, pode ser lido em fluxo e facilita localizar diretamente a linha quando um registro falha. Para arquivos de log grandes e fluxos de eventos, o JSONL é mais adequado do que um array único.

Por que linhas em branco são ignoradas?

Linhas em branco geralmente vêm de copiar e colar, da rotação de logs ou de edição manual e não representam registros de dados reais. Ignorá-las reduz o ruído sem abrir mão da verificação rigorosa de todas as linhas que contêm conteúdo.

E se uma linha for um array, uma string ou `null`?

Esta página vai classificá-la como linha inválida, porque o formato-alvo é «cada linha não vazia é um objeto JSON». Se seus dados realmente precisam armazenar arrays ou valores primitivos linha por linha, não é o cenário típico de log JSONL para o qual esta página foi otimizada.

Por que não dá para copiar logo todo o resultado quando há uma linha inválida?

É uma interação deliberadamente conservadora. A cópia só é permitida quando todas as linhas não vazias são válidas, para evitar que um resultado parcialmente certo e parcialmente corrompido siga para importadores, scripts ou colegas, poupando uma segunda rodada de investigação.

Ele me ajuda a encontrar arquivos de log truncados?

Sim. Muitos problemas de JSONL acontecem nas últimas linhas: por exemplo, um objeto sem `}`, uma string sem aspas de fechamento ou um fluxo de rede interrompido no meio. A página expõe diretamente a linha inválida correspondente, especialmente útil para downloads incompletos e interrupções de saída em fluxo.

JSONL e NDJSON são a mesma coisa?

Na imensa maioria dos contextos de engenharia podem ser tratados como sinônimos. Ambos indicam registros JSON separados por quebras de linha; só muda o hábito de nomenclatura.

Ao formatar JSONL, meus dados são enviados?

Não. Toda análise, validação e formatação é executada apenas localmente no navegador; logs, respostas de API, arquivos de sessão e exportações de dados não são enviados a servidor nenhum.

Quando devo usar o formatador JSON comum em vez do formatador JSONL?

Se a entrada em si é um objeto JSON completo ou um array, como o corpo de uma resposta de API, um arquivo de configuração ou um pacote de dados tipo `[{...},{...}]`, deve-se usar a página de formatação JSON comum; só quando a entrada são registros de objetos separados por quebras de linha é que esta página JSONL é mais adequada.

Glossário

JSONL: Formato de texto com registros JSON separados por linhas. A forma mais comum na engenharia é cada linha não vazia ser um objeto JSON completo.
JSON Lines: O nome completo e outra denominação comum para JSONL, normalmente tratado como sinônimo.
NDJSON: Newline Delimited JSON, literalmente «JSON delimitado por quebras de linha». Na maioria dos cenários de log e pipeline de dados é praticamente equivalente ao JSONL.
Registro por linha: Layout de dados em que cada linha representa um registro completo, adequado para escrita e leitura em fluxo e para localizar erros por linha.
Pretty Print / formatação legível: Reorganizar um JSON compactado de uma linha em uma estrutura legível com indentação e quebras de linha, para facilitar a inspeção manual dos níveis de campos.
Linha inválida: Uma linha que não é JSON válido ou que, embora analisável, não corresponde à estrutura esperada (por exemplo, não é um objeto) e, por isso, não constitui um registro JSONL válido.
Fluxo truncado: Um log ou exportação interrompido no meio durante transmissão, descarga ou gravação, fazendo com que o último registro não fique completamente fechado.
Array JSON: No JSON padrão, uma coleção inteira envolvida por `[` e `]`, por exemplo `[{...},{...}]`. Diferente do JSONL, precisa ser analisado como um único documento.

Authoritative References

jsonlines.orgDescrição oficial do JSON Lines
IETFEspecificação oficial JSON RFC 8259