Como formatar JSON minificado para conseguir ler de verdade

O JSON minificado chega em uma linha só porque o espaço em branco entre tokens não significa nada em JSON. Para ler, passe o texto de volta por um parser e imprima de novo com indentação: cole a linha no formatador de JSON, mantenha a indentação de dois espaços e ela volta como uma árvore. O espaço em branco nunca é o risco: acrescentar ou remover não muda nem um valor. Quem muda as coisas é a volta pelo parser, e uma dessas mudanças perde dados caladinha.

Por que ele chegou em uma linha só

A RFC 8259 nomeia exatamente quatro caracteres como espaço em branco insignificante entre tokens: espaço, tabulação, quebra de linha e retorno de carro. Insignificante quer dizer que o parser pula esses caracteres sem olhar. Minificar um documento JSON é só apagar todos os que estiverem fora de uma string: o espaço dentro de uma string é dado e fica exatamente onde está.

O motivo de alguém se dar ao trabalho é que a indentação ocupa uma fatia real de um arquivo formatado. A dois espaços por nível, uma linha aninhada quatro níveis abaixo carrega oito espaços iniciais mais uma quebra de linha: nove bytes de nada. Um arquivo de 5.000 linhas cujas linhas têm essa profundidade média carrega 45 kB de layout antes do primeiro caractere de dados.

Na rede isso importa menos do que essa aritmética sugere. Qualquer coisa que sirva JSON com juízo manda com gzip ou brotli, e sequências longas de espaços idênticos são o padrão mais fácil que um compressor vai encontrar na vida. Minificar continua ganhando, só que por uma margem menor do que a contagem de bytes dá a entender.

Como formatar

Quatro lugares, dependendo de onde o texto já está.

• No navegador. Cole e escolha uma indentação. É o caminho mais rápido quando o JSON saiu da aba de rede ou de uma mensagem de chat e ainda não está em um arquivo. Também tem um teto: o formatador daqui parseia na thread principal da página, então alguns megabytes são tranquilos e uma exportação de banco de dados vai travar a aba por segundos ou ficar sem memória.
• No seu editor. Salve o texto com a extensão .json e rode Format Document na paleta de comandos do VS Code, ou o equivalente no que você usar. A vantagem é que o editor fica com o arquivo e depois deixa você recolher as seções.
• Na linha de comando. python -m json.tool lê a entrada padrão e imprime indentado sem instalar nada. jq . faz o mesmo com indentação de dois espaços e cor de sintaxe, e jq -c . volta para o outro lado quando você precisa da forma compacta de novo.
• Sem formatar nada. O painel Network do Chrome tem uma aba Preview que mostra uma resposta JSON como uma árvore que dá para recolher, e o Firefox vem com um visualizador de JSON que faz o mesmo com qualquer resposta servida como application/json. Para dar uma olhada rápida em uma resposta, isso ganha de ficar copiando texto de um lado para o outro.

O que a volta pelo parser muda

Um formatador não sai salpicando quebras de linha pelo seu texto. Ele parseia o documento até virar um valor e imprime esse valor de novo do zero. Tudo que não fazia parte dos dados não sai do outro lado.

• Os números são normalizados. 1.0 volta como 1 e 1e3 como 1000. O valor sobrevive; o jeito como estava escrito, não.
• Os escapes são reescritos na forma legal mais curta. \u0041 volta como A e \u002F como /, enquanto \u0009 volta como \t. Os caracteres de controle continuam escapados dos dois jeitos, já que o JSON os proíbe crus dentro de uma string.
• As chaves duplicadas se juntam em uma. A especificação diz que os nomes DEVERIAM ser únicos e deixa o resto indefinido. JavaScript e Python ficam os dois com a última, então uma configuração com "timeout" duas vezes perde uma delas no caminho, normalmente sem dizer nada.
• Chaves que parecem números mudam de lugar. {"2":"b","1":"a"} é reimpresso com "1" primeiro. Isso é uma regra de objeto do JavaScript, não do JSON, e é a única reordenação que você não consegue desligar.
• Comentários não existem. JSON não tem, então um arquivo que tenha comentários nunca foi JSON e não vai nem parsear.

A mudança que realmente perde dados

Os inteiros grandes. A especificação do JSON não põe limite no tamanho nem na precisão de um número, mas o JavaScript guarda todo número como um float de 64 bits, então os inteiros acima de 9.007.199.254.740.991 não podem todos ser representados com exatidão. Dê a um parser JavaScript o valor 9007199254740993 e você recebe 9007199254740992 de volta, sem erro nenhum em lugar nenhum.

Isso cai primeiro sobre os identificadores: IDs de banco de dados, snowflakes do Discord, timestamps em nanossegundos. É por isso que APIs bem-feitas mandam IDs grandes como strings. O formatador deste site procura literais inteiros que mudam quando o JavaScript lê e diz quais são, mas não consegue consertar: quando o valor existe, os dígitos já se foram. Se você vir esse aviso, trate a saída formatada como insegura para colar de volta em qualquer coisa que importe.

Por que o erro diz linha 1, coluna 4812

É assim, especificamente, que o JSON minificado estraga o seu dia. Está tudo em uma linha só, então o parser informa um número de coluna na casa dos milhares e você não tem onde olhar. Você não consegue formatar o arquivo para achar o problema, porque o problema é justamente o motivo de ele não formatar.

Duas saídas. Cole a linha em um editor e use a caixa de ir para uma posição: a do VS Code aceita line:column, então digitar 1:4812 deixa o cursor no caractere em questão. Ou pule isso e vá descendo a lista das coisas que costumam estar erradas, porque a lista é curta:

• Uma vírgula sobrando antes de um } ou de um ].
• Strings com aspas simples ou chaves sem aspas. JavaScript válido, JSON inválido.
• Uma resposta truncada, que aparece como um fim de entrada inesperado bem na última coluna.
• NaN ou Infinity de um serializador que deveria saber das coisas. Nenhum dos dois é JSON legal.
• Não ser JSON de jeito nenhum: uma página de erro HTML copiada da aba de rede, que falha logo no primeiro <.

Diga o que disser a posição, lembre que ela é onde o parser desistiu, não onde você errou. Uma vírgula faltando é reportada no começo da chave seguinte, e uma string não fechada é reportada na próxima aspa que aparecer. Olhe um pouco antes do número que te deram.

Alguns arquivos estão quase lá, não quebrados. JSON5 e JSONC permitem comentários e vírgulas sobrando e vão falhar em qualquer formatador estrito, inclusive o nosso. NDJSON —um objeto por linha, sem array em volta— também falha, porque a segunda linha é entrada inesperada; envolva você mesmo as linhas em um array antes. Se o que você queria mesmo era um formato de configuração que deixe escrever comentários, o trade-off entre YAML e JSON é a versão honesta dessa pergunta.

Como ler depois de indentado

A indentação sozinha não torna compreensível um objeto de 4.000 linhas. Duas coisas ajudam antes de você começar a rolar a tela.

A primeira é a forma. A profundidade de aninhamento e a contagem de chaves dizem qual problema você tem: um payload cinco níveis abaixo com quarenta chaves se lê de um jeito bem diferente de um dois níveis abaixo com quatro mil. O formatador imprime a profundidade e a contagem de chaves acima da saída, que é o jeito mais barato de descobrir qual dos dois você tem antes de começar a rolar.

A segunda é a ordenação. Ordenar as chaves em ordem alfabética torna um objeto desconhecido pesquisável, e é seguro por definição, já que os membros de um objeto não têm ordem. Também é destrutivo de um jeito que importa nos arquivos que as pessoas mantêm: o agrupamento do autor normalmente carregava significado. Ordene uma resposta que você está inspecionando, não um arquivo de configuração que você está prestes a commitar.

A ordenação compensa quando você está comparando dois payloads. Formate os dois com as chaves ordenadas e passe por um diff linha a linha: sem ordenar, você recebe um diff cheio de linhas que só mudaram de lugar, e o único campo que realmente mudou fica enterrado ali.

E se o JSON acabar sendo um array plano de objetos —uma lista de linhas com as mesmas chaves—, a indentação é a visualização completamente errada. Trezentos registros são ilegíveis como árvore e óbvios como tabela, que é para isso que serve converter JSON para CSV, junto com os campos que se perdem quando você faz isso.

Onde o JSON minificado não para de aparecer

As respostas de API são a fonte óbvia, mas não a única. Qualquer coisa escrita no localStorage ou em um atributo data- passou pelo JSON.stringify, que não acrescenta espaço em branco a menos que você peça. Linhas de log estruturado são minificadas para que um evento fique em uma linha só. E o segmento do meio de um JWT é JSON minificado codificado em base64url, e é por isso que decodificar um token te entrega uma parede de texto: você recebe o JSON de volta, ainda em uma linha só, e ainda precisa indentar.

Todos eles fazem bem em continuar minificados onde moram. A ideia não é arrumar a origem: é ter uma cópia legível na sua frente pelos dois minutos em que você precisa dela, e depois jogar fora.

Última atualização 19 de setembro de 2026