Formatador JSON

Formata, comprime e valida JSON. Selecione o recuo para formatar com legibilidade ou comprima em uma linha. Erros de sintaxe são verificados na hora.

Entrada JSON
Resultado formatado JSON válido JSON inválido
{{ result.lines }} linhas / {{ result.bytes.toLocaleString() }} bytes
{{ result.error }}

O que faz um formatador de JSON

Um formatador de JSON toma um JSON espremido numa só linha e o desdobra de novo com recuo, ou faz o contrário: retira os espaços e o devolve a uma única linha. Como para qualquer das duas coisas precisa analisar a entrada, diz de passagem se a sintaxe está correta, de modo que colar uma resposta de API ou um arquivo de configuração lhe dá formatação, compressão e validação de uma vez. O recuo pode ser de dois espaços, de quatro ou de uma tabulação.

Quem julga é o próprio analisador de JSON do navegador, portanto você não esbarrará no desencontro de algo passar aqui e falhar no seu ambiente de execução. Tudo ocorre dentro do seu equipamento: o JSON que você cola nunca é enviado a um servidor. Mesmo uma resposta que leve um token de autenticação ou dados pessoais pode ser arrumada sem que nada saia da máquina.

Como usar o formatador de JSON

  1. Cole o JSON Cole-o na caixa de entrada da esquerda. Se não tiver nada à mão, o botão de amostra carrega um exemplo.
  2. Escolha o recuo Opte por dois espaços, quatro ou uma tabulação. Ajustando-o às regras do seu projeto, poderá colar o resultado de volta sem retoques.
  3. Confira a marca de válido ou inválido A marca muda conforme você digita. Quando o JSON é inválido, mostra-se tal como está a mensagem de erro do analisador, de modo que dá para seguir em que linha e em que caractere ele parou.
  4. Copie o resultado formatado ou o comprimido «Copiar formatado» leva à área de transferência o resultado com recuo; «copiar comprimido», a única linha sem espaços.
  5. Leia a contagem de linhas e de bytes As linhas são contadas sobre o resultado formatado e os bytes sobre o comprimido, medidos em UTF-8. Para estimar quanto vai transferir, atenha-se ao segundo.

Dicas para aproveitar melhor

  • As chaves do JSON devem estar sempre entre aspas duplas. Aspas simples são inválidas.
  • Vírgula final ({"a":1,}) é inválida segundo a especificação JSON.
  • Números em notação científica são válidos. No entanto, NaN e Infinity são inválidos.
  • Aspas duplas dentro de strings precisam ser escapadas com \". Quebras de linha são \n e tabulações são \t.
  • A compressão é útil para reduzir o tamanho de arquivos. Para transferências via API prefira a versão comprimida; para arquivos de configuração, a formatada.

Onde um formatador de JSON ajuda

Ler uma resposta de API

Formate uma resposta que chegou numa só linha e a profundidade do aninhamento e o número de elementos de cada arranjo passam a ser seguidos com a vista. É de longe o uso mais frequente, tanto ao desenvolver quanto ao perseguir uma falha.

Localizar um erro de sintaxe num arquivo de configuração

Quando um aplicativo se recusa a carregar a sua configuração, colar o arquivo e validá-lo aponta a causa na hora: uma vírgula final, uma aspa sem fechar.

Comprimir para transferir menos

Devolver JSON formatado como resposta de API ou como dados embutidos desperdiça banda só com o recuo. Para tudo o que é servido, use a versão comprimida.

Arrumar exemplos para documentação ou para um chamado

Deixe os exemplos de requisição e de resposta que vão numa especificação ou num relato de erro numa forma legível e de recuo parelho.

Preparar a entrada antes de convertê-la

Confirmar antes a sintaxe poupa erros obscuros do outro lado quando você entregar os dados a JSON para tipos de TypeScript ou a JSON para XML.

Termos relacionados ao JSON

JSON
Sigla de JavaScript Object Notation, o formato de troca de dados fixado na RFC 8259. Constrói-se com apenas seis coisas — objeto, arranjo, cadeia, número, booleano e null — e, como qualquer linguagem pode lê-lo e escrevê-lo, tornou-se o formato padrão das API web.
Formatação (pretty-print)
Refazer o texto com recuos e quebras de linha que seguem a profundidade do aninhamento, para que uma pessoa possa lê-lo. Os dados não mudam; muda só o seu aspecto.
Compressão (minify)
Retirar todo espaço e quebra de linha que não carregue significado e deixá-lo numa só linha. O número de bytes cai, portanto transfere-se menos, mas deixa de ser pensado para o olho humano.
Validação
Conferir que a entrada segue a gramática do JSON. Esta ferramenta deixa o trabalho ao analisador do navegador e mostra a mensagem de erro dele ao pé da letra quando falha.
Sequência de escape
Maneira de escrever, com uma barra invertida, caracteres que não podem ir tal como estão dentro de uma cadeia. As aspas duplas são \", a quebra de linha \n, a tabulação \t.
Ordem das chaves
O próprio JSON não fixa ordem alguma para as chaves de um objeto. Como esta ferramenta passa os dados por um objeto de JavaScript, só se reordenam de forma ascendente as chaves que se leem como inteiros — "1", "2" e afins. Toda outra chave conserva o lugar em que foi escrita.
UTF-8
A codificação de caracteres que a RFC 8259 exige para o JSON. Os caracteres fora do ASCII ocupam vários bytes cada um, de modo que a contagem de caracteres e a de bytes não coincidem.

Perguntas frequentes

As chaves devem estar obrigatoriamente entre aspas duplas, vírgulas finais não são permitidas, e undefined, funções, NaN e Infinity não podem ser usados.

Não. A especificação JSON não possui sintaxe para comentários. JSON5 e JSONC são usados como alternativas.

O RFC 8259 exige UTF-8. Recomenda-se UTF-8 por questões de interoperabilidade.

Na especificação JSON todos os números são do tipo number. Inteiros muito grandes podem perder precisão ao ultrapassar o MAX_SAFE_INTEGER do JavaScript.
Tool-kun

Curiosidade — Por que o JSON venceu o XML

No início dos anos 2000, o XML era o padrão dominante. Em 2001, Douglas Crockford propôs o JSON — mais leve, simples e legível — e a partir dos anos 2010 o JSON tornou-se o padrão da indústria.

Para os mesmos dados, o JSON costuma ter entre 30 e 50% menos bytes que o XML, o que na era das comunicações móveis impactava diretamente a velocidade de resposta das aplicações.

No RFC 8259, chaves duplicadas são "SHOULD NOT", não proibidas. {"a":1,"a":2} é sintaticamente válido, mas seu comportamento é indefinido.