Validador de sintaxe JSON

1. 1Cole ou envie JSONCole o seu JSON no editor, ou arraste um arquivo .json, .jsonc, .json5, .ndjson, .geojson ou .webmanifest para a área de soltar. JSON minificado e formatado funcionam, e nada é enviado para lugar nenhum.
2. 2Clique em ValidarTodos os erros de sintaxe aparecem de uma vez com a sua linha, coluna e deslocamento em bytes, e um cursor marca o caractere exato. JSON válido mostra em vez disso o tipo raiz, o tamanho e a estrutura.
3. 3Leia também os avisosChaves duplicadas e números que perdem precisão são JSON perfeitamente legal que todos os parsers aceitam em silêncio. Aparecem como avisos com um JSON Pointer para cada um, porque são as falhas que sobrevivem até produção.
4. 4Corrija, ou deixe a ferramenta corrigirClique num resultado para levar o cursor até ele. Se o texto for JSON5, JSONC ou um dicionário Python em vez de JSON quebrado, a ferramenta avisa e oferece uma cópia reparada para aplicar ou baixar.

Verifique a validade do seu JSON em segundos, com a localização exata do erro, a resposta do parser e um resumo estrutural para depurar rapidamente. Cole ou envie JSON e clique em Validar para obter de imediato uma aprovação ou uma falha. Quando é válido, você vê o tipo raiz, o seu tamanho e um relatório completo de estrutura. Quando não é, você vê todos os erros de uma vez — cada um com a sua linha, coluna, deslocamento em bytes e um cursor sob o caractere exato — além dos avisos que nenhum outro validador mostra: chaves duplicadas e números que mudam de valor em silêncio ao serem analisados. Tudo roda no seu dispositivo, por isso payloads privados, tokens e esquemas internos nunca saem dele.

• Todos os erros, de uma vez — Um parser para na primeira falha. Este se ressincroniza e continua: um arquivo com quarenta falhas custa uma passagem, não quarenta.
• A mesma localização em todo lugar — Linha, coluna, deslocamento em bytes e um cursor, calculados a partir dos bytes em vez de extraídos de uma mensagem do navegador — idênticos no Chrome, Firefox e Safari.
• As falhas que passam em outros lugares — Chaves duplicadas e números que perdem precisão são JSON legal. São também a forma como os dados desaparecem sem ruído, por isso são reportados como avisos.
• Esquema, dialetos e reparação — Verifique contra um JSON Schema, descubra que o seu arquivo é afinal JSON5 e leve uma cópia reparada num clique.
• Colar ou enviar — Cole da área de transferência, solte um arquivo ou procure-o. Redefinir limpa a entrada e o resultado em conjunto.

A coisa mais útil que um validador pode lhe dizer é onde olhar, e é justamente aquela que a maioria dos validadores online faz de forma menos confiável. Repetem o que diz o parser integrado do navegador, e essas mensagens não são iguais em todos.

Medido nos três motores reais: o parser do Safari reporta «JSON Parse error: Expected '}'», sem posição, sem linha e sem coluna. O Firefox dá linha e coluna mas nenhum deslocamento de caractere. Só o Chrome dá os três. Um validador que lê essas mensagens com um padrão funciona bem num navegador em cada três e se degrada em silêncio nos demais.

• Linha e coluna — Contadas em caracteres, não em bytes, para que uma linha que comece por uma palavra acentuada não indique uma coluna com que o seu editor não concorde.
• Deslocamento em bytes — O que você precisa quando o arquivo é tratado por um script e não por um editor.
• Um cursor sob a falha — A linha em questão, com o caractere exato marcado. Numa linha longa o excerto é recortado em torno da falha, não no início.
• Um JSON Pointer — Onde a falha está na estrutura do documento — /users/3/email — e não apenas no texto.

Um parser JSON existe para produzir um valor, por isso assim que encontra algo que não consegue usar lança uma exceção e para. É o comportamento certo para um parser e pouco útil para um validador: corrigir a vírgula que falta na linha 12, rodar outra vez, descobrir a chave sem aspas na linha 40, rodar outra vez.

Este validador não está construindo um valor, por isso não tem nada a abandonar. Quando encontra um símbolo que não encaixa em lugar nenhum, registra a falha e se ressincroniza — tratando uma vírgula faltando como se estivesse lá, fechando um contêiner que encontrou o parêntese errado — e segue até o fim do arquivo. O resultado é a lista inteira numa passagem. Deixa de registrar aos mil resultados, muito além do ponto em que um arquivo vale a pena ser corrigido à mão em vez de regenerado.

• Separadores ausentes — Uma vírgula ou dois-pontos ausentes são tratados como erro de digitação e a análise continua, em vez de se propagar num erro em cada membro seguinte.
• Parênteses trocados — Um fecho que não corresponde à abertura fecha o contêiner mesmo assim, para que um deslize não transforme o resto do arquivo em ruído.
• Strings não terminadas — Uma string à qual falta uma aspa termina no fim da sua linha em vez de engolir o resto do documento.

O JSON permite a mesma chave duas vezes num objeto. A especificação se abstém de dizer o que deveria acontecer, e a resposta prática é que todos os parsers atuais ficam com a última ocorrência e descartam a primeira sem avisar.

Assim, um arquivo de configuração com uma chave definida duas vezes é válido, e metade dele não faz nada. Uma resposta de API combinada com um campo repetido é válida, e um dos dois valores desapareceu. Como é legal, isto fica em aviso e não em falha — o veredito precisa concordar com o parser que realmente vai consumir o arquivo — mas é reportado com um JSON Pointer para cada ocorrência e o deslocamento da primeira, para que possa ver ambas.

• Exato, não aproximado — As chaves são comparadas pelo seu valor decodificado, por isso uma chave escrita "a" e a mesma escrita com um escape são corretamente reconhecidas como a mesma.
• Por objeto, não por documento — A mesma chave em dois objetos irmãos é normal e não é reportada. Só uma repetição dentro de um mesmo objeto o é.
• A qualquer profundidade — Uma duplicata vinte níveis abaixo é encontrada, com o ponteiro que leva até ela.

O JSON não limita o tamanho nem a precisão de um número, e quase todos os parsers os leem em ponto flutuante de 64 bits. Acima de 9 007 199 254 740 991 um inteiro não pode mais ser representado exatamente, por isso é arredondado — em silêncio, sem erro e sem aviso em nenhum ponto da cadeia.

Não é um problema teórico. IDs Snowflake, identificadores ao estilo do Twitter, números de pedido e valores contábeis vivem todos nessa faixa, e o sintoma é um registro que não se encontra porque o seu ID voltou desviado umas centenas. O validador verifica cada literal numérico que possa ser afetado e reporta o valor exato ao lado do valor que um parser vai produzir.

• Inteiros grandes — Comparados com exatidão, usando aritmética de precisão arbitrária em vez do valor em ponto flutuante que é precisamente o que está em questão.
• Decimais longos — Um decimal que não pode ser recuperado do double em que se torna é reportado com o valor a que será realmente arredondado.
• Transbordo e subtransbordo — 1e400 torna-se Infinity e 1e-400 torna-se zero. Nenhum é representável em JSON, e nenhum gera erro em nenhum outro lugar.
• Barato quando não se aplica — Um literal de quinze dígitos ou menos não pode perder nada, por isso é totalmente ignorado. Só os que podem ser afetados são examinados.

Uma boa parte dos arquivos dados como «JSON inválido» não está quebrada de forma alguma. Está escrita num dialeto: JSONC, que acrescenta comentários e vírgulas finais, ou JSON5, que permite ainda chaves sem aspas, aspas simples, números hexadecimais e NaN. O seu editor os lê sem problema; um parser estrito recusa-os.

O tsconfig.json, o .eslintrc e a maioria dos arquivos de configurações de editores são JSONC. Um dicionário copiado de uma sessão Python parece JSON mas usa True, False e None. Em vez de chamar tudo isso de quebrado, o validador nomeia o que está vendo, lista quais construções são responsáveis e oferece uma cópia em JSON estrito.

• Comentários — Comentários de linha e de bloco são reconhecidos — e apenas fora das strings, para que uma URL com barra dupla fique intacto.
• Vírgulas finais — Uma vírgula antes do fecho, assinalada na vírgula e não no parêntese.
• Aspas e chaves nuas — Strings entre aspas simples, chaves sem aspas e as aspas tipográficas que um processador de texto deixa.
• Literais que não são JSON — NaN e Infinity, números hexadecimais, um mais ou um ponto decimal iniciais, e True, False e None do Python.

Cada reparação vem de um resultado que o analisador já localizou, nunca de um padrão aplicado ao documento inteiro. Essa distinção pesa mais do que parece: uma expressão regular que remove comentários também apaga a barra dupla dentro de "https://example.com", e uma que remove vírgulas finais também apaga a vírgula dentro de "a, b,". O analisador sabe que bytes estavam dentro de uma string e quais não estavam, por isso não comete nenhum desses erros.

O documento reparado é depois revalidado antes de ser oferecido, e se continuar inválido é apresentado como correção parcial com as falhas restantes enumeradas. Um botão que diz «Corrigido» e devolve algo que não analisa é pior do que não haver botão.

• O que é corrigido — Comentários, vírgulas finais, aspas simples e aspas tipográficas, chaves sem aspas, números hexadecimais, mais ou ponto iniciais, e True, False e None do Python.
• O que é assinalado como com perda — NaN e Infinity não têm forma de se escrever em JSON. Tornam-se null, e a mudança é anunciada em vez de feita em silêncio.
• Aplicar ou baixar — Coloque o texto reparado diretamente no editor, ou baixe-o como arquivo .json.

A sintaxe é só metade da pergunta. «Tem a forma certa?» é a outra metade, e é a isso que um JSON Schema responde. Cole um no painel e o documento é verificado também contra ele, com cada falha trazendo um JSON Pointer para o valor em causa e a linha onde está.

Draft 2020-12 e draft-07 são ambos suportados, e o draft é lido de $schema — ou deduzido quando o esquema não o declara, o que acontece com quase todos os escritos antes de 2020. Essa dedução importa: a forma de array de items no draft-07 significa outra coisa em 2020-12, e ler uma como a outra produz uma resposta confiante e errada em vez de um erro.

• Todo o vocabulário de validação — type, enum, const, os limites numéricos, comprimento e padrão de strings, restrições de arrays e objetos, required e as palavras-chave dependentes.
• Aplicadores — allOf, anyOf, oneOf, not, if/then/else, prefixItems, contains, propertyNames, e tanto unevaluatedProperties como unevaluatedItems.
• Referências — $ref, $defs, definitions, $anchor e o escopo de $id resolvem-se dentro do esquema que você fornecer. Uma referência para outro servidor é reportada pelo nome e nunca baixada.
• format, tal como a especificação o define — Uma anotação por padrão, exatamente como ambos os drafts dizem: um esquema com "format": "email" não recusa um endereço incorreto a não ser que você peça. Há uma opção para quem esperava o contrário.

Um valor JSON por linha é como se escrevem os pipelines de logs, as exportações do BigQuery, os corpos de API em lote e os conjuntos de treino. Lido como um único documento JSON, um arquivo desses produz exatamente um erro — conteúdo a mais no início da linha dois — tecnicamente correto e completamente inútil.

O modo NDJSON valida cada registro separadamente, por isso uma falha é reportada contra o registro em que está. O modo é sugerido automaticamente quando um arquivo parece delimitado por linhas, e é sugerido em vez de aplicado: uma ferramenta que reinterpreta a sua entrada em silêncio é uma ferramenta sobre a qual não se consegue raciocinar.

• Resultados por registro — Cada falha traz o seu número de registro além da linha e da coluna, e a contagem de registros aprovados é reportada ao lado.
• A quebra de linha final — Todo produtor termina o último registro com uma quebra de linha. Essa última linha vazia não é um registro, e tratá-la como tal acrescenta um erro fantasma a quase todos os arquivos bem escritos.
• Fins de linha do Windows — Um retorno de carro deixado no fim de um registro seria, de outro modo, um caractere de controle dentro do seu último símbolo — um erro por linha em qualquer arquivo escrito no Windows.
• Registros vazios — Uma linha em branco no meio é reportada em vez de ignorada. O formato não tem separador, por isso uma linha vazia significa que um registro foi escrito vazio.

Um arquivo pode ser JSON perfeitamente correto e ainda assim falhar por causa de três bytes invisíveis. Uma marca de ordem de bytes UTF-8 — o que o Out-File do PowerShell, o StreamWriter do .NET e a exportação «UTF-8» do Excel escrevem — fica antes da chave de abertura, e um parser estrito reporta um símbolo inesperado na posição 0 para um documento, fora isso, impecável.

O UTF-16 é pior, porque é o que o Windows PowerShell escreve quando não se indica codificação nenhuma. Lido como UTF-8 parece ter um byte NUL depois de cada caractere, e o erro aponta para algo que ninguém consegue ver. Ambos são aqui detectados e tratados, e a codificação usada é reportada para que nada aconteça nas suas costas.

• UTF-8, com ou sem marca — A marca é reconhecida, retirada e reportada. O documento é validado como se ela nunca tivesse estado ali.
• UTF-16, com ou sem marca — Detectado pela marca, ou por onde caem os bytes NUL — os caracteres estruturais do JSON são todos ASCII, por isso o padrão é conclusivo e não um palpite.
• Bytes mal formados — Um byte que não é UTF-8 válido é reportado como aviso, não como veredito: um navegador o substitui antes de qualquer parser o ver, por isso não pode invalidar um documento — mas significa que o arquivo não está na codificação que aparenta.
• Nada de texto — Uma imagem renomeada para .json é recusada com esse motivo, em vez de produzir um erro de sintaxe na posição 0 para algo que nunca foi JSON.

Uma única passagem sobre os bytes, sem enviar nada para lugar nenhum. Um documento de 22 MB é verificado em cerca de 0,2 segundos num notebook comum — incluindo chaves duplicadas e precisão numérica — porque o analisador nunca constrói os valores que verifica.

• Válido — Um veredito verde com o tipo raiz e o tamanho, e um relatório de estrutura: total de nós, profundidade máxima, contagem de objetos, arrays e chaves, o tamanho em linhas e bytes, e a codificação usada.
• Inválido — Um veredito vermelho com todos os erros enumerados — linha, coluna, JSON Pointer, uma descrição clara e um cursor sob o caractere exato — além de um link para o Formatador JSON.
• Avisos — Chaves duplicadas, números que perdem precisão, escapes de substitutos sem par e aninhamento incomumente profundo, cada um com a sua localização. Não mudam o veredito, porque um parser os aceita.
• Um dialeto, quando existe — Se o texto for JSON5, JSONC ou um dicionário Python válido, isso é dito por extenso, com a opção de o converter.

JSON inválido quebra APIs, configurações e pipelines de dados, e costuma quebrá-los longe de onde está o erro. Verificar antes de enviar ou salvar detecta erros de digitação, vírgulas faltando, vírgulas finais e caracteres sem escape enquanto ainda tem o arquivo à frente. Os avisos importam mais: uma chave duplicada ou um identificador arredondado não produzem erro em lugar nenhum, por isso sobrevivem a todos os testes e aparecem como dados ausentes semanas depois. Todas as verificações rodam localmente, por isso os seus dados continuam privados.

• Detectar erros cedo — Encontre problemas de sintaxe antes que quebrem uma implantação ou uma integração, com a linha e a coluna exatas em vez de um rastro de um servidor.
• Detectar os silenciosos — Chaves duplicadas e perda de precisão passam por todos os parsers e todos os validadores existentes. São as falhas que chegam a produção.
• Verificar a forma, não só a sintaxe — Um JSON Schema transforma «analisa» em «é o que o consumidor espera», antes que o consumidor descubra.
• Privacidade — Nada é enviado. Respostas de API privadas, tokens de acesso e esquemas internos podem ser verificados sem sair do seu dispositivo.

Tudo o que decide se um documento é válido é grátis. Todos os erros em vez do primeiro, chaves duplicadas, avisos de precisão, JSON Schema, detecção de dialeto, reparação, modo NDJSON e o relatório completo de estrutura estão disponíveis de graça. O Pro acrescenta escala, não funcionalidades.

• Grátis — Um arquivo de cada vez, até 25 MB, mais colagem sem limite. Todas as verificações, todos os avisos, validação com esquema e reparação incluídas.
• Pro — Até 100 arquivos numa passagem, tamanhos limitados pelo seu dispositivo e não por nós, um ZIP de relatórios para todo o lote, e relatórios JSON e CSV legíveis por máquina para um passo de CI ou um ticket.
• Por que 25 MB — É uma medição, não um número redondo. Um documento de 22 MB é verificado em cerca de 0,2 segundos, por isso o limite fica onde um celular intermediário ainda está à vontade.

• Formatador JSON
• Minificar JSON
• Visualizador JSON
• Comparar JSON
• Ordenar chaves JSON
• Remover chaves JSON