Arquivo JSON grande não abre? Escolha a ferramenta certa pelo tamanho

Um arquivo JSON de 45 MB é processado em 249 milissegundos. O meio minuto de espera vem da renderização de cinco milhões de linhas de texto e 3,5 milhões de nós de árvore. Confunda os dois e sempre culpará o errado.

Um: meça primeiro — o parsing nunca é o gargalo

Dois cliques num export .json de dezenas de MB, o editor gira por trinta segundos, e o reflexo diz "o parsing do JSON é lento". As medições dizem o oposto. Nossa máquina (Node 22) gerou uma amostra de 500.000 registros com cinco campos cada (id, email, active, score, tags), 45 MB na forma compacta:

O parsing terminou em um quarto de segundo. O parser terminou antes de você soltar o mouse. Todos os segundos seguintes foram gastos na camada de "mostrar o resultado a uma pessoa": o editor de texto precisa paginar cinco milhões de linhas, aplicar realce de sintaxe e manter um buffer de desfazer; a visualização em árvore precisa criar um elemento DOM para cada um dos 3,5 milhões de nós — e os navegadores tropeçam perto de cem mil nós, perdendo a resposta bem antes de um milhão.

A conclusão aponta numa direção completamente diferente: pare de lutar contra a renderização e use uma ferramenta que não renderiza tudo.

Dois: por que trava — a contagem de linhas e nós é o custo real

O tamanho do arquivo é só a superfície. Dois números derivados quebram as ferramentas:

1. Contagem de linhas. Um JSON compacto de 45 MB vira cinco milhões de linhas quando formatado. Não importa qual trecho você verá, o editor precisa primeiro construir a estrutura de linhas do arquivo inteiro, resolver o estado de realce e alocar buffers — custos proporcionais ao total de linhas.
2. Contagem de nós. Meio milhão de registros × (um objeto + cinco campos) são 3,5 milhões de nós. Qualquer visualizador que constrói a árvore inteira antes de mostrar paga a mesma memória e tempo, expanda você um ramo ou todos.

Duas consequências contraintuitivas. Formatar antes de olhar atrapalha — o arquivo cresce de 45 para 71 MB e as linhas multiplicam por quarenta, pressão puramente extra para a ferramenta. Jogar o arquivo com cat no terminal também atrapalha — o buffer de rolagem vira o novo gargalo; para os primeiros bytes, head -c 2000 basta.

Três: escolha a ferramenta pelo tamanho — tabela de decisão

Tamanhos diferentes pedem ferramentas completamente diferentes. Combinando as medições acima com referências publicadas (OpenFormatter coloca a zona de conforto das ferramentas online em 2-5 MB; PureJSON estima memória de 2-4 GB após processar um documento de 500 MB), a tabela fica assim:

A ferramenta /parse deste site cobre o primeiro degrau: visualização em árvore e validação. Arquivos maiores pertencem ao aplicativo de desktop, para que dezenas de MB nunca sejam colados numa página web.

Quatro: não abra o arquivo — pergunte primeiro pela estrutura

Diante de um JSON grande desconhecido, o primeiro movimento não é abrir, mas gastar alguns segundos entendendo a estrutura. O jq responde a três perguntas em cerca de 200 ms:

复制# Array ou objeto no topo? Quantos registros?
jq 'if type == "array" then {type: "array", count: length} else {type: "object", keys: (keys|length)} end' huge.json

# Como é o primeiro registro (um só, sem enchimento)?
jq '.[0]' huge.json | head -40

# Todos os nomes de campos (do primeiro registro)
jq '.[0] | keys' huge.json

Conhecida a estrutura, a maioria das demandas se reduz a "extrair um campo" — o arquivo nem precisa ser aberto. Por exemplo, para pegar o e-mail de cada usuário:

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

A regra é simples: para olhar, um visualizador com renderização virtualizada; para buscar e extrair, jq. Não misture os dois papéis numa única ferramenta.

Cinco: o penhasco de memória — modo normal contra streaming, 150× de diferença

Na mesma amostra de 45 MB, o /usr/bin/time -v mediu o pico de memória do jq em dois modos:

O modo normal lê o arquivo inteiro e constrói o grafo de objetos; o pico de 542 MB confirma a regra "grafo de objetos ≈ 7-12× o tamanho do texto". O --stream consome a entrada token a token, mantendo a memória em poucos MB — ao custo de um tempo total maior. Passado o marco do gigabyte, essa diferença separa "funciona" de "morto pelo OOM killer":

复制# Para arquivos maiores que a memória: --stream é o único modo que nunca carrega tudo
jq --stream -n 'fromstream(1|truncate_stream(inputs))' huge.json

O equivalente em Python é o ijson: ijson.items(f, 'item') entrega os elementos do array um a um com a mesma memória constante. O preço comum dessas ferramentas é abrir mão do acesso aleatório — um stream é uma única passada adiante, e uma segunda passada exige reler o arquivo.

Seis: até onde o navegador chega — limites do processamento local

Ferramentas online servem, dentro de limites. Uma aba moderna de navegador tem cerca de 1-4 GB de memória; um arquivo de 45 MB processado em grafo mais árvore geralmente sobrevive. Algumas centenas de MB já beiram o penhasco. Ao escolher um visualizador online, exija três coisas:

1. Processamento acontece localmente (o conteúdo colado nunca vai para um servidor), o que protege os dados e economiza tempo de upload — todas as ferramentas deste site rodam inteiramente no navegador e funcionam offline;
2. O parsing roda num Web Worker — a thread principal não congela, e um travamento custa uma aba, não o navegador inteiro;
3. A árvore é virtualizada ou de expansão preguiçosa — ramos recolhidos quase não custam nada; só o que é expandido é renderizado.

Neste site: /parse serve para explorar estrutura e localizar erros em arquivos até algumas dezenas de MB; acima disso, jq ou o aplicativo de desktop, reservando o navegador para pequenos trechos.

Sete: o formato certo elimina metade dos problemas

Se você influencia como o arquivo é gerado, um visualizador melhor é o remédio errado — faça com que ele não cresça até virar "um único array gigante":

• NDJSON/JSONL: um registro por linha. Acrescentar não reescreve o arquivo, e head, grep, tail, split funcionam direto; um arquivo truncado perde só a última linha. Nosso manual de JSONL cobre em detalhe o tratamento de linhas quebradas.
• Exportações paginadas: uma API que devolve 100.000 registros deveria aceitar parâmetros de paginação — 100 por vez é melhor para os dois lados.
• Dados tabulares não são JSON: um registro por linha, campos fixos sem aninhamento — isso é uma tabela. CSV ou Parquet são menores e têm ecossistemas mais ricos.

Um número para lembrar: corte um array de 500.000 registros ao meio, e a primeira metade continua sendo um arquivo NDJSON válido (metade dos registros sobrevive), enquanto o array único correspondente se perde por completo. 500 registros recuperados de 501 valem mais que zero.

Oito: checklist

• Sondar a estrutura primeiro com jq '.[0] | keys' ou uma amostra de 500 registros;
• Nunca formatar só para abrir o arquivo — dobrar as linhas só deixa tudo mais lento;
• Abaixo de 2 MB: visualização em árvore online; acima de 20 MB: linha de comando; acima de 1 GB: sempre --stream ou ijson;
• Confirmar que a ferramenta online processa localmente (o conteúdo colado não sai do navegador);
• Se você controla o gerador, mude para NDJSON ou paginação e elimine arrays gigantes na origem.

FAQ

Por que o editor leva dezenas de segundos para abrir o JSON se o programa processa em 200 ms?

O parsing é código nativo convertendo texto em estruturas de dados: 249 ms na nossa amostra de 45 MB. O editor trava na apresentação: cinco milhões de linhas para paginar, realçar e manter no buffer de desfazer; a árvore constrói DOM para 3,5 milhões de nós. Um visualizador virtualizado ou extração direta com jq contorna tudo.

O jq estoura memória em JSON acima de 1 GB?

No modo normal, sim: ele carrega o documento inteiro, com o grafo de objetos atingindo pico de 7-12× o tamanho do arquivo. Com --stream, a entrada é consumida token a token: nosso teste de 45 MB atingiu pico de 3,6 MB, e a memória fica plana independentemente do tamanho — ao custo de uma única passagem sequencial.

Qual tamanho de arquivo as ferramentas JSON online suportam?

A maioria fica confortável até 2-5 MB e degrada claramente acima de 10 MB. O teto rígido é a memória da aba (cerca de 1-4 GB), mas já em algumas dezenas de MB a espera do parsing e da construção da árvore dói. Acima de 20 MB, use ferramenta local ou linha de comando.

Como ver o valor de um campo num JSON enorme?

Extraia com jq sem abrir o arquivo: jq -r '.[].email' huge.json imprime todos os e-mails; com filtro, jq -r '.[] | select(.active == true) | .email'. Para os primeiros registros, jq '.[0:5]' huge.json — ordens de grandeza mais rápido que abrir o arquivo.

Formatar antes de abrir ajuda?

Não. Formatar transforma 45 MB compactos em 71 MB e uma linha em cinco milhões, adicionando puro ônus ao editor e ao visualizador. Reserve a formatação para o que uma pessoa lerá — e só se o arquivo for pequeno o bastante.